Nikolaos Papagrigoriou

Solutions Architect and DevOps Consultant

DDD - Modelling the Domain - Aggregates

The concept of Aggregate was introduced by Evans (2003) as a reference term to a “cluster of associated objects that we treat as a unit for the purpose of data changes”. In other words, an Aggregate defines a set of Entities and Value Objects that are collaborating as an atomic unit whose state is always valid (Evans, 2003). Among all DDD building blocks, the Aggregates is the most misunderstood (Vernon, 2013).

DDD - Modelling the Domain - Modules

Software systems could become very complex with a large domain model which makes it overwhelming to see the whole picture. The concept of a Module is a design element in many programming languages (in Java they are called Packages and in C# Namespaces) to divide code for managing complexity and assisting in code reuse. Typically, programming language textbooks promote modules mainly as a code organization tool.

DDD - Modelling the Domain - Services

When designing a Domain Model the prominent modelling paradigm is objects and as a result we are mapping concepts i.e. nouns to DDD building blocks such as Entities and Value Objects. The behaviour associated to those concepts is mapped to methods using verbs. However, there are domain specific functions that we would like to define in the model but cannot be attached into an existing Entity or Value Object (Evans, 2003). Instead of forcing foreign operations into domain objects, Evans (2003) introduced the concept of Domain Services.

DDD - Modelling the Domain - Value Objects

There are elements of the Domain Model without any conceptual identity which are typically used to characterise Entities (Evans, 2003). Those elements are called Value Objects and their significance is often neglected (Vernon, 2013). Examples of Value Objects are: Zip Code, Order Number, Phone Number, Money, Currency, Date, Date Range, E-mail Address, URL etc. Value Objects express domain concepts and are part of the Ubiquitous Language (Evans 2003; Vernon, 2013).

DDD - Modelling the Domain - Entities

Entities are objects of the domain model with a distinct identity and a life cycle (Evans, 2003). Moreover, the key defining characteristic is not the values of their properties which could change over time (Evans, 2003). The uniqueness of an Entity's identity is defined by the model and does not change during its lifetime (Evans, 2003).

Architectures

Software applications are typically composed of a User Interface (UI), code to process input from a user or another system and a database that acts as the persistence mechanism. Python applications could incorporate the UI, the business logic and the data access into a single file. For very simple applications this might make sense. However, as the complexity of the domain rises there is a need to divide code intro separate files within many directories and create separate code packages. The aim of this high level code organization is separation of concerns.

Domain Driven Design and Ubiquitous Language

Domain-Driven Design (DDD) is an approach to drive complex software projects using a set of principles, software design practices and techniques by directly aligning the code with the concepts in the domain (Evans2003). The concept was established by Eric Evans in his book “Domain-Driven Design, tackling complexity in the heart of software”. Vaughn Vernon notes that Evans' book “is essentially a large pattern language” (Vernon2013).