Implementing Code: Tactical DDD Patterns

This section is about tactical DDD patterns, which you can learn from the book Domain-Driven Design by Eric Evans. It is unnecessary to explain them here again if there is such a fantastic book out there already. Instead, I plan to draw your attention toward the intricacies essential for a successful application of the mentioned patterns. I will do so by dedicating a brief section to various concrete constructs from the specified group.

Therefore, a prerequisite for reading subsequent sections is to learn the basics about tactical DDD patterns.

Entity

Entities are business objects. A common confusion exists between entities and DTOsData Transfer Objects. To avoid misconceptions in this direction, please read my article about this topic. In short, entities typically encapsulate behavior by ensuring the consistency of an internal state. On the other hand, a DTO is always consistent, so no particular encapsulation is necessary.

Entities that look like DTOs

Can an entity look like a DTO? It absolutely can. This kind of design is applicable if an entity’s state stays consistent by changing any single property atomically. When you deal with such DTO-like objects, there is no need to invest in a state encapsulation since it is consistent no matter what. Encapsulation is only necessary when we want to ensure an atomic transition from one valid state to another, namely through a method invocation to alter multiple fields simultaneously.

Active Record entities

Active Record is a pattern when we treat a database-persisted object as a business entity.

The motivation behind Active Record is in the ...