DDD - Anti-pattern
In the context of Domain-Driven Design separating business logic from the Domain Model is an anti-pattern, which is usually described by the term Anemic Domain Model (Evans, 2003; Fowler, 2003).
In the context of Domain-Driven Design separating business logic from the Domain Model is an anti-pattern, which is usually described by the term Anemic Domain Model (Evans, 2003; Fowler, 2003).
Enterprises need big complex software systems and many software developer teams have to collaborate. Often, a project starts with one shared domain model and each team is responsible to design and develop a part of it. The teams might be spread in different buildings or even around the world and communicate sparingly.
The role of a Repository is to abstract away the database infrastructure by retrieving and persisting aggregates, their entities and value objects, giving the illusion of an in-memory data store (Evans, 2003). Typically, for each domain object that has a unique identity and needs persistence, we need to define a Repository in the Domain Model (Evans, 2003).
In Object-Oriented programming there are many design patterns to create objects that were mainly popularised by Gamma et al (1995). It should be stressed out that “favouring object composition over class inheritance” (Gamma et al, 1995) is central to Domain-Driven Design which raises the importance of the creational patterns, hereafter referred to as Factories (Evans, 2003). In short, Factories are objects that have a single responsibility i.e. to encapsulate the logic of creating other objects (Evans, 2003).
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).
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.
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.
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).