Creating Low-Code Solutions

Introduction to Domain Driven Design

The Domain Driven Design (DDD) approach is a collection of rules and guidelines in order to model large and complex systems. Modelling refers to the representation of a real-world situation in which it is possible to visualize relationships and actions between different substances. Thus, making the ideation process and, later, the implementation process less painful and more organized by avoiding errors and misunderstandings.

In the DDD approach, the focus is on the core domain and domain logic. A model is a distilled form of domain knowledge, assumptions, rules and choices. The DDD approach is also helpful in the implementation phase as it offers patterns and principals for building well-organized and delicate systems. Additionally, it provides a mutual way of communication between experts in different fields by defining a ubiquitous language within prespecified contexts which are called bounded contexts.

Ubiquitous language is a language structured around the domain model and used by all team members. Bounded contexts refer to a group with similar characteristics that act in a similar way. In one system there could be more than one bounded context and these contexts can communicate with each other. Each solution is a bounded context in the Solution Designer. A Context Map is an overview of several bounded contexts, their relationships and interfaces.

Furthermore, within a bounded context we will find aggregates.These are, again, a group, but this time smaller in size than the bounded context, that is comprised of entities that refer to the same theme. An entity refers to a specific object. It has a consistent identity and its own lifecycle. There are many types of entities, but we will focus on the basic ones that are used in the Solution Designer. These are the following:

  • Entities

    Entities are simple objects that have their own identity and lifecycle. They can contain properties or other entities, can be nested in other entities and root entities.

  • Root Entities
    Root entities are the entry-point to a cluster of entities. This encapsulated cluster is called “aggregate” and has the following characteristics
    • Only the entry point root entity can have references from other entities outside of the aggregate.
    • An aggregate is a transactional atomic.
    • It can have references to other root entities outside of the aggregate.
    • It has exactly one database collection where the whole aggregate is stored in.
    • All contained entities have the same dependent lifecycle.

    Additionally, root entities can contain properties or other entities, can have commands and can have other root entities as parents or children.

  • External Entities

    External entities are entities referring to so called known entities that are situated in integration namespaces. This way, entities from external sources – be it third party APIs or other solutions of the Solution Designer – can be integrated into and consequently used within your solution.

    External Entities can contain Properties or constructor properties and can have known entities.

Now that we described the basic elements that constitute the ontology of a system, we should describe how actions can occur. For starters, in order to achieve coherence of different occurrences we use what we call Events. These are used when we would like to acknowledge that something has happened. To make this clearer, imagine an automated heating system that is sensor based. This system works as follows: when a room is empty the heating system is turned off. When a person enters the room, the motion sensors detect this change and shout “There is a human in the room”. This would be, in our case, the event.

Moreover, the central heating system, which is responsible for turning on the heat when there is a person inside the room, would listen to the message that the event published and activate the heating system according to the specifications. This would be an example of an Agent in Domain Driven Design. More specifically, agents normally listen to events and then they perform a prespecified action which is basically the result of an already completed action. In summary, when some action has been performed or a standard situation has changed then an event is triggered, notifying the world that this change has been made and following that, the correspondent agent will respond to the event by performing a follow up action.

Finally, we will now describe another important functionality, and this is called Service. A service is used to apply changes to multiple aggregates at the same time or to perform complex actions that may require information from multiple namespaces or entities or even other services. In addition, services can be consumed by external resources. For example, services can be connected to UI frameworks and this way a complete application can be developed.