Today, I will continue with DDD. My goal is 50 pages which is around the start of Chapter 7.
Modules (Packages)
Like everything else in a DDD, modules are a communication mechanism.
The same idea still prevails. Try to design to the domain. Modules should flow naturally.
Also keep modules and organization simple. A domain model should be represented as a domain model not a technical one.
Aggregates
A cluster of associated objects that we treat as a unit for the purpose of data change.
Consists of:
- Root a Specific entity, only object which can be referenced from the outside
- Boundary defines the content of the aggregate
Factories
Requirements:
- Each creation method is atomic and enforces all invariants
- Parameters of factory method should use the abstract type
Invariant checking makes the most sense in the case of value objects because they are immutable. In the case of entities the factory should use the entity’s methods to check invariants.
Repositories
A repository takes care of all queries and summary information about a collection. It’s like a SQL/DB layer however the technology behind it doesn’t matter.
if you find you need to search the database for a preexisting value object, it is worth considering the possibility that you’ve really got an entity whose identity you haven’t recognized.
Some terminology:
- Anti-Corruption Layer: \Translation layer between domain model and outside API
- Enterprise Segment: A way to break data down (time, attributes, etc.)
Listen to the language the domain experts use. Are there terms that succinctly state something
complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks
on their faces go away when you use a particular phrase? These are hints of a concept that might
benefit the model.
And read a book about the domain! It often contains explanations and models.
Specification
- states a constraint onto an other object; can test if object fulfils specifications
Purposes:
- Validate object
- Select object
- Constrain creation
Supple design
How to strive balance between change and the domain mode
Intention-Revealing Interfaces
But if the interface doesn’t tell the client developer what he needs to know in order to use the object effectively, he will have to dig into the internals to understand the details anyway
Describe what classes and operations do, not how.
Side-Effect-Free Functions
An operation that mixes logic or calculations with state change should be refactored into two separate operations
Standalone Classes
Low coupling is fundamental to object design. When you can, go all the way. Eliminate all other concepts from the picture. Then the class will be completely self-contained and can be studied and understood alone. Every such self-contained class significantly eases the burden of understanding a module.
Closure of Operations
Where it fits, define an operation whose return type is the same as the type of its argument(s).
I quite like his ideas about declarative specifications. The idea is that besides checking specifications you also include boolean operators. So you can write something like:
A.and(B) which returns a new specification which checks for A and B.
Updates Goals:
- Get a bit more exposure to OOP and OOD
- Learn a bit more about MySQL
- Learn Symfony2
- Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
- Watch one video per day on average
Progress status
In Progress
- Read Domain-Driven Design [293 of 560 pages]
- Watch one video per day on average [47 of 75]