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.
分享到:
相关推荐
NULL 博文链接:https://xj84.iteye.com/blog/2065681
在微服务(Microservices)架构实践中,人们大量地借用了DDD中的概念和技术,比如一个微服务应该对应DDD中的一个限界上下文(Bounded Context);在微服务设计中应该首先识别出DDD中的聚合根(Aggregate Root);...
SpringMVC第12讲:<mvc:annotation-driven/>
Domain driven design distilled
我个人认为DDD最大的好处是将业务语义显现化,把原先晦涩难懂的业务算法逻辑,通过领域对象(Domain Object),统一语言(Ubiquitous Language)将领域概念清晰的显性化表达出来。相信我,这种表达带来的代码可读性...
Domain Driven Design is a very good book for exper
With Implementing Domain-Driven Design, Vaughn has made an important contribution not only to the literature of the Domain-Driven Design community, but also to the literature of the broader enterprise...
Applying Domain Driven Design and Patterns,根据网上chm版本制作的pdf版本,效果很好!
<mvc:annotation-driven /> <context:component-scan base-package="Controller" /> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/...
Domain-Driven Design Distilled. Vaughn Vernon.2016
Domain Driven Design with Spring Boot epub version
.NET Domain-driven design with C# sulotion source
JavaScript Domain-Driven Design allows you to leverage your JavaScript skills to create advanced applications. You'll start with learning domain-driven concepts and working with UML diagrams. You'll ...
Domain-Driven Design in PHP Real examples written in PHP showcasing DDD Architectural Styles, Tactical Design, and Bounded Context Integration
关于DDD可参考InfoQ的Mini Book Domain Driven Design Quickly , 还有 Banq 的文章 实战DDD(Domain-Driven Design领域驱动设计), 和 领域模型驱动设计(DDD)之模型提炼 。 本书分为四部分,第一部分讲述了领域模型...
domain-driven design
Implementing Domain-Driven Design,比较经典的DDD学习资料,全英文版,爱读原版的应该比较喜欢;
a quick guide on domain driven design