domain-driven-design学习

[b]Why DDD？[/b]
1. 业务领域是一个应用程序的核心，使用DDD，直接面对核心业务，可增强业务需求确认速度，可以尽快暴露业务上的缺陷、风险。
2. 使用OO对核心业务进行建模，增强可扩展性、可维护性。domain model是核心业务，由POJO实现，不依赖于任何框架、数据库，不管想使用WEB方式或是Swing，或者移植到任何平台，domain model都不需要改变。
3. 解除了业务领域代码与非业务领域代码（如UI代码或持久层代码）的耦合，产生如下好处：
1）使代码修改、扩展更加轻松
2）使代码自动化测试更加容易
3）业务领域代码直接清晰的反映了业务需求

[b]应用程序的分层[/b]
UI Layer --> Application Layer --> Domain Layer --> Infrastructure
UILayer就是用户接口，用户的直接操作界面，相当于Swing、Web页面；
Application Layer：应用层，服务器端的用于处理Application Logic的层次，也可以叫做Application Service，也可以说是一个domain model的facade。
Domain：包括几种类型的对象，后面有详细说明
Infrastructure:持久层或者其他网络应用层次


[b]Domain model中的几个对象[/b]
1. Entity
具有唯一标识ID的对象，任何一个Entity对象在整个业务流程中都是唯一的，即便两个Entity对象的所有属性都相同，但具备不同的标识符，都是属于不同对象。
2. Value Object
不具备唯一标识的对象，通常被设计为Immutable；Entity和Value Object不能靠是不是被持久化来区分，value object也可能会被存储到数据库或文件系统中
3. Factory
用于创建domain对象，对于对象创建流程复杂的业务对象，需要使用Factory进行创建，以对客户端隐藏业务细节。
4. Repository
用于对domain对象进行添加、查找、删除等操作，一般都要与infrastructure进行交互，以接口方式定义。
5. Service
Service是一个domain object functionality operation的集合，没有状态，只提供Operation。通常会跨多个domain object，作为domain object间相互调用的一个接口。这样的operation如果定义在domain object中，会在domain object间形成一个强耦合，不利于修改、扩展。service中的方法可以认为是一个use case的操作序列，通常以接口方式定义。

与以前的三层结构的service比较 presentation + service + persistence
以前三层中的service包含业务逻辑，也包含与持久层的耦合，service层很厚，将很多业务逻辑全都写在里面，这样的service复用性及可维护性不高，只是针对一个客户端（这里指表现层）调用给出一个接口，是基于客户端请求的，而客户端这些请求有些时候仅仅是为了界面显示的需要，如在页面上要显示两个列表以便用户查看，像这种需求并不能体现真正的业务逻辑，而且这样的service根本不能被重用。在Martin Fowler的企业模型中定义的service layer 的概念，应该是很薄的一层，提供了用于客户端调用的facade，里面只包含应用层的逻辑（如上述的列表显示要求），而不是业务逻辑。