Designing the DDD way — Introduction
Before entering into the domain driven design world, there are some jargons that needs to be understood.It’s really important to get these concepts cleared as every time you delve into these DDD discussions, you will hear them often
Value Object — Any object which is immutable. The classification of a particular object as VO, solely depends on the context in which it is used. One question to be asked about any object to be classified as a VO or not is whether it is ever acceptable for an intermediate state of the given object.If the answer is no, then it qualifies to be a VO. Also a value object does not have any identity of it’s own, it is always identified by the entity in which it is defined
eg. Name for any customer is always going to be Value object.(more info)
Entities — They have behavior and can change state . They have an identity. Anything that has continuity can be classified as an aggregate.
Aggregate — An aggregate is a collection of domain objects or entities.The transactional integrity is always maintained inside an aggregate.
Ubiquitous Language: It’s a common language for terms to be used between developers and business/domain experts to define the objects
Invariants — Invariants are generally business rules/enforcements/requirements that you impose to maintain the integrity of an object at any given time.
The crux of DDD lies in the approach you take towards the problem statement. And most often, it’s not always about only having a domain knowledge but also understanding/questioning the business needs holds the key to DDD style of functioning.
DDD talks very closely with the business and businesses change requirements to survive every quarterly results tide. Every change in invariants results in your evolving domains, resulting in the need to refactor the code to respect the invariants.
And the best way to understand it by citing an example.
A bank has many customers and each customer can open a bank account. The account should be removed and not accessible the moment it’s account balance becomes 0. (looks like this bank serves underground agents :P )Customer is identified with his social security number(SSN). The other information is his address which should have line1,city,country.
Enter the DDD world, and you will say
Aggregate or Root entity : Customer . identifier for customer is SSN
Value object: Address.
Business invariant :account should be removed when balance in account drops to 0.
Entity: Account, with attributes balance. It will have an identity(can be account number)
Conclusion: This was all about introduction to jargons used in Domain Driven Design.
