Before chapter 1, it introduced the main Content of the book.
1. Domain model provides a ubquitous language that ties domain experts and technologiests together.
2. Domain modeling and implementation should not be seperated and should belong together. Domain models aren't first modeled and then implemented, but evloved over time.
3. Domain design is closely related to the agile development process. Iterative development(XP,...); close relationship between developers and domain experts. DDD and agile reinforce each other.
4. The heart of software is its ability to solve domain related problems for its user. But some talented developers tend to pay more attention to the technologies used than the domain problem. They should deal with the complexity of the domain with high priority.
Part I
Chapter 1
It use the PCB chip net example to illustrate how a model help to crunching knowledge between developers and domain experts. Also introduced the cargo voyage example.
Chapter 2
It says we need a ubiquitous language to communicate between software developers and domain experts. This language can pervade every medium of communication.
Chapter 3 Binding Model and Implementation
1. Model-Driven Design demands a model that works well both for analysis and design.
2. Development is an iterative process of refining model, the design, and the code as a single activity.
3. Overseperation of responsibility for analysis, modeling, design, and programming interferes with Model Driven Design, althrough it does not mean that team members can not have specialized roles.
4. Large projects still need technical leaders who coordinate high level design and modeling and help work out the most difficult or most critical decisions.
Part II
The navigation map diagram
Chapter 4 Isolating the Domain
1. Layered Architecture: User Interface, Application, Domain, Infrastructure
2. Online Banking into layers example. (Not focused on the design of the isolated domain layer yet)
3. Relating the layers. Upper layers call public interfaces of lower levels directly. Communite upwards by callbacks or OBSERVERs. Connecting UI, application, domain by MVC like pattern. Infrastructure is offered as SERVICES.
4. Architectural Frameworks. Help to solve technical problems and let domain developer to concentrate on expressing a model. Choose frameworks only when it is necessary or only use the necessary parts in it.
5. The Domain Layer is where the model lives. Isolating the domain implementation is a prerequisite for domain-driven-design.
6. Smart UI "Anti-Pattern". DDD's learning curve is difficult. It is supposed to be used for complex project with necessary experts.
Chapter 5 A Model Expressed in Software
1. Associations: pretty much the same with OOA and OOD
2. Entities are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.
3. Value Objects have no conceptual identity. They describe some characteristic of a thing.
4. Services are operations or actions that do not conceptually belong to any object.
5. Services and the Isolated Domain Layers: Application services(send message service), Domain Services(Funds Transfer service).
6. Modules. Using packaging to separate the domain layer from other code. Otherwise, leave the domain developers to package the domain objects in ways that support their model and design choices.
7. Modeling Paradigms. The dominant paradigm is object oriented design. But a domain model does not have to be an object model. There are DDD implemented in Prolog, with a model made up of logical rules and facts.
Chapter 6 The life Cycle of a Domain Object
The diagram about the lifecycle.
Three patterns.
1. Aggregates
----An aggregates is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggreate has a root and a boundary.
----A set of rules about aggregates: Root entity has global id and responsible for checking invariants; Entities inside an aggregates has local identities. Reference constraints; Only root can be obtained directly from db. Inside reference to outside aggregate root. Deletion. Invariants satisfied while change is committed.
----Purchase Order Integrity example.
2. Factories
----Responsible for creation of domain objects: Entities, Value objects,
----Each creation object is atomic and enforces all invariants of created object or aggregate.
----Creation Patterns.
----Factory method in the aggregate root VS standalone factory for aggregate.
----Constructor VS Factory.
----Reconstituting stored object.
3. Repositories
----Encapsulating data persistence. Let the client talk to a simple, intention-revealing interface, and ask for what it needs in terms of the model.
----Provides Repositories only for aggregate roots that actually need direct access.
----Client Code ignores repository implementation; developers do not
----Repositories VS Factories: The factory make new objects, the repository finds old objects
... ...
Part IV
Chapter 14
Relationships between bounded contexts
1. Shared Kernel
Problem:
Uncoordinated teams working on closely related applications. What they produce may not fit together
Solution:
Designate some subset of the domain model that the two teams to share. Shared kernel can include domain model, database design, or even code. Integrate the functional system frequently, but not as often as CI.
2. Customer/Supplier
Problem:
One subsystem feeds another. All dependency goes one way.
Solution:
Representatives of the downstream team play customer role.
Jointly develop automated acceptance tests.
3. Conformist
Problem:
Upstream has no motivation to provide the downstream team's needs, the downstream team is helpless.
Solution:
Abandon the use of the upstream.
Slavishly adhering to the model of the upstream team.
4. Anticorruption Layer
Problem:
New systems have to be integrated with legacy or other systems. The difficulty can eventually overwhelm the intent of the new model.
Solution:
Create an isolating layer. It translates conceptual objects and actions from one model and protocol to another.
5. Separate Ways
Problem:
Integration is always expensive. Sometimes the benefit is small.
Solution:
Why bother? Let them evolve in their own ways.
Anyway, the features can sitll be organized in middleware or the UI layer.
6. Open Host Service
Problem:
A subsystem has to be integrated with many others. There is more and more to maintain, and more and more to worry about.
Solution:
Define a set of SERVICES that give access to your subsystem. Enhance and expand these services to handle new integration requirements.