Tactical Domain-Driven Design provides the artefacts to express, create and retrieve the domain model. These form the tactical design of the system and are listed below:
- Entity: an object that is not defined by its attributes, but rather by a thread of continuity and its identity. It is something that has a distinct separate existence though it need not be a material existence. It can be a container for functionality.
- Value Object: an object that contains attributes but has no conceptual identity. They should be treated as IMMUTABLE. They help express intent in code adn aids unit testing. This acts as a container for computational complexity.
- Attributes: is a specification that defines a property of an object, element or file.
- Aggregate: a collection of objects that are bound together by a root entity.
- Aggregate root: provides an entry point and exposes an API for operations on the aggregate (organisation of small collaborations between related objects). This helps limit coupling. It also provides consistency by forbidding objects holding references to its members. It also manages concurrency and transactions within the aggregate’s boundary; however it doesn’t load the complete entity graph into memory.
- Repository: provides a persistence mechanism that can be easily interchanged for alternative implementations if required. It provides a simple delegation of responsibility away from the domain objects. Martin Fowler describes theses as a layer super pattern. Repositories represent an in-memory collection. This implies ONE REPOSITORY PER AGGREGATION ROOT. This provides separation of model code from infrastructure.
- Factories: encapsulates complex object creation. The methods for creating domain objects should delegate to a specialised factory object such that alternative implementation could be easily interchanged. This abstracts the actual type created. It is useful for constructing aggregates.
- Services: some operations don’t fit into entities. These are best placed into a service which requests a single stateless operation. Never create a generic service. Always look to putting functionality into entities and value types.
- Domain Events: these are used to model interesting events to construct state and improve performance. Don’t throw these into an Entity Service Broker/Bus -> understand the domain.