Skip to main content

What is a Domain

Cognibase Domain Concept​

In Cognibase, the term Domain holds a special significance. Conceptually it is the data model that solves a specific problem. Additionally it is a foundational element for how data transactions are orchestrated within the system. Here's an in-depth look at this concept:

What is a Domain?​

A Domain in Cognibase is a group of classes (Entities) that are built to solve a problem. They all inherit from the DataItem abstract class and are marked with a Class attribute like PersistedClass or RuntimeClass. The fields/properties that are managed by Cognibase are also marked with a special attribute like PersistedProperty or RuntimeProperty. Additionally they should have a specific implementation. The DataItem classes are typically encapsulated within a single .NET assembly, giving them a cohesive representation of a specific problem or business context. This assembly is marked with an assembly attribute RuntimeDomain. Although, the usage of POCO objects is favored nowadays in ORM libraries, offering both simple programming paradigm and capabilities like real-time synchronization need specific implementation in framework level and Entity level.

Declarative Programming​

Cognibase offers declarative data modeling through .NET attributes, allowing developers to specify various aspects of entities classes and fields as metadata. This includes options to define whether a class or field is persisted or memory-only (runtime), caching preferences, field loading, and monitoring capabilities. Such declarativity exists also in the Domain level, where various aspects of the Domain ar set through attributes. Read more on Declarative Programming in Data Modelling page.

Relationship with UML & DDD​

The domain representation in Cognibase closely aligns with the UML Class Diagram and Entity Relationship Diagram concepts, which makes it intuitive for developers familiar with object-oriented design and modeling. This design choice not only provides a robust foundation for data representation but also allows for better alignment with the problem domain.

While Cognibase's concept of Domain has nuances unique to its architecture, it also shares similarities with the Domain Driven Design (DDD) methodology. DDD emphasizes modeling based on the actual problem domain, and Cognibase's approach resonates with this idea, ensuring that the technical implementation remains close to the business context.

How is the Domain used?​

The domain assembly/DLL file is integrated into both the Cognibase Object Server and the Client Applications. This ensures a consistent representation of the data and its associated business logic across the entire system.

Initially, the Object Server uses the domain DLL to generate the DB Schema by reading the aforementioned attributes and the DB specific driver. This is a Code-First approach. When there is an update of the DataItems object model, the Object Server updates the DB Schema by generating the appropriate SQL update script. Except of managing the Relational Schema, the Object Server among others uses this object model to validate the changesets that the clients send. Additionally, because it instantiates the actual objects it can run additional business rules and custom code. Data-First, i.e. custom mapping, and Model-First approaches are also considered for next releases.

In the client space, the DataItem instances are used normally in the application layer. The Client Object Manager then validates the changeset against the object model rules and then sends the changeset to the Server to become a transaction.

Transactions and Synchronization​

Any data transaction initiated within Cognibase always occurs within the bounds of a Domain. This transactional boundary ensures consistency, reliability, and a predictable state of data. Once a transaction is completed, the changes are synchronized across the connected clients, ensuring that every participant has an up-to-date view of the data.

By understanding and effectively leveraging the Domain concept, developers can create robust, consistent, and scalable solutions. The emphasis on modelling close to the business problem ensures that solutions are not just technically sound, but also align well with the actual business needs and contexts.

The Internals of a Domain​

For a .NET class library project to be considered a Domain, the following prerequisites should be met:

  • Have the RuntimeDomain assembly attribute.
  • Have a Factory implementation, sub-classed from the DataItemDomainFactory class. This is then registered in the Client Application bootstrap code.
  • Contain Entity classes sub-classes of the DataItem class.

Data Representation​

Cognibase has a modular architecture regarding the data storage. In fact the Object Server is mostly agnostic of the underlying storage technology. We call Adapters the modules that implement the actual data access layer per technology. The Data Storage representation of the DataItems is specific to the used adapter. For example, in Binary-Files adapter we use one file per DataItem plus some special files. In SQL based adapters there are two tables per DataItem and a couple of special tables. You can read more details on the Data Storage page.

Future Directions​

A model first approach for building the Domain is under investigation. We are considering on constructing a new Modelling Language that can support the various capabilities of Cognibase. Additionally the custom mapping (Data-First) approach is under investigation taking in consideration the capabilities of standard ORMs like Entity Framework.