Tactical Modeling
Domain odel inside a Bounded Context
Last updated
SC - Software Architecture
Domain odel inside a Bounded Context
Last updated
In Tactical Modeling, we learn how to decompose the Domain Model, how I distribute my Business Rules into different Objects (Domain Objects) so that I can implement this in Code.
You can adopt DDD Tactical Modeling without adopting the Strategic Modeling.
Ex.: You can use DDD in a monolith, you used Domain Objects without breaking your monolith into different sub-domains (which would kind of make it as a Microservice architecture)
To build the Domain layer (Ex.: layer in Clean Architecture) we use the Tactical Modeling.
DDD at Tactical level, complements Clean Architecture.
Is a set of Domain Objects, used to distribute the business complexity.
A Domain Model protects Mutation, protects the State, distributing rules of the Domain into Domain Objects.
Entities <E> abstract the Independent Business Rules.
They have an Identity and a State that mutates over time.
Identity means it will have an unique identifier that distinguishes one Entity from another.
Ex.: An Account have a accountId.
State means a property that will have its value changed over time for any reason.
Ex.: A Ride will have a status that changes over time.
Identity can be manually generated in the application like UUID or automatic generated from a Database like Sequences.
Value Objects <VO> also have Independent Business Rules.
However they don't have Identity nor State, they are identified by their value and should be immutable.
Changing/Updating the value of a Value Object implicates on it's entire substitution.
Ex.: To change the value you simply create a new one.
Value Objects represent a value.
Ex.: CPF or Social Security are values that can also have independent rules, like validation rules. (Depending on the Domain, they could be Entities since they could have state)
Other Ex.: Dimensions, Coordenates, Email, Color, etc.
Domain Services <DS> do specific tasks from a Domain.
They are stateless and should be used for tasks that don't belong to any Entities or Value Objects.
Using Domain Services in place of Entities or Value Objects, favors an Anemic Domain.
Aggregates <A> are groupings, or clusters of Domain Objects like Entities and Value Objects, while establishing relationships between them (like Foreign Keys).
Aggregates are relationships at application level, and not necessarily means Database relationships.
Big Aggregates can bring memory waste and overload on the data base without need.
Always try to balance the invariance presenvation with resource consumption.
Create small aggregates, starting with only an Entity and growing only as needed.
Reference other Aggregates by Identity, maintain only references to other Aggregates, thus reducing resource consumption and effort for Repositories to recover them.
When Persisting Aggregates:
The Aggregate persistence should always be done with the ENTIRE Aggregates, BUT in the Repository implementation you can decide which records of the database must be updated.
Ex.: When updating Coordinate Positions from a Ride, you can update only a specific Position record, instead of re-inserting all of them from scratch every time.
When Reconstructing Aggregates:
The invariance preservation depends on the Aggregate integrity, this means that if part of it is not populated it loses integrity.
The aggregate must always be fully used, even if you will only need part of it.
If you only need part of the Data, then retrieve it from a DAO. But if using Repositories always retrieve ALL the data to reconstruct the Aggregate in VALID state.
Aggregate Root <AR> is the Entity that leads the Aggregate.
Is an extension of the Domain, and responsible for persisting Aggregates, separating the Domain from Infrastructure.
Repositories ONLY persist Aggregates, and not only Entities or Value Objects.
This is for preserving the Aggregate integrity and avoiding Invalid States.
DAO is table oriented, so it only needs to preserve and respect that. (Table columns, column data types, and so on)
This means that DAO won't check data integrity at business level.
Repositories on the other hand, guarantees that persisted Aggregates are in VALID states. And not just when writing on Database but also when reading from it.
If the objective is to only get data from the Database and return it, use a DAO.
