Service design

Ubiquitous language is a language structured around the domain model and is 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 project is a bounded context in 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 than the bounded context, that comprises 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 Solution Designer.

These are the following:

• 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 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 the aggregate

  • an aggregate is a transactional atomic

  • it can have references to other root entities outside 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 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 projects of the Solution Designer) can be integrated into and consequently used within your project. 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 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 pre-specified 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.