DDD领域模型开发

聚合(Aggregation):
     这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.
     用来表示拥有关系或者整体与部分的关系。
组合(Composition):
这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.
在一个合成里，部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成部分的支配权。包括他们的创建和毁灭。

这两个非常的相似，
聚合：
• 聚合有时能够不依赖部分而存在，有时又不能
• 部分可以独立于聚合而存在
• 如果有一部分遗失，聚合会给人一种不完全的感觉
• 部分的所有权可以由几个聚合来共享，比如打印机
[通过接口设置]
组成：
• 部分某一时刻只能属于某一个组成
• 组成唯一的负责处理它的所有部分--这就意味着负责他们的创建与销毁
• 倘若对于部分的职责由其他对象来承担的话，组成也就可以放松这些职责。
• 如果组成销毁的话，它必须销毁所有的部分，或者把负责他们的权利转移给其他对象。
[通过代码组合]

模型驱动设计(Model-DrivenDesign)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型！

领域模型把分析和设计放在一起,单一的领域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新模型。[只用单一的模型来满足分析与设计,不能满足就重新寻找模型]如何寻找模型？模型又是一个什么?
根据Eric的理论，业务层将细分为两个层次：应用层和领域层。

应用层：定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题，保持精练；不包括业务规则或知识，无业务情况的状态；Action[这个代码更改的概率为0]

领域层：负责表示业务概念、业务状态的信息和业务规则，是业务软件核心。层次之间必须清晰分离，每个层都是内聚的，并且只依赖它的下层.[在领域 层会建立模型，比如用户模型,保存了用户的所有属性，用户所有的功能,全部面向接口，依赖下层实现，也就是以抽象的方式建立模型，就也就是在分析和设计的 时候设置的用户模型，比如以下类图]


分析与设计[设置顶级接口很重要]
用户顶级接口 User
Java代码
1. UserInfo  getUserInfo()  --得到用户信息:用户属性  
2. void Speak()       --说话:用户功能 
3. void Walk()        --走路:用户功能 

         
看到这里会不会觉得用户接口很简单，很简洁.[爆露给外部调用的方法，在设计的时候已经确定]

用户接口的功能内聚，用户模型保存用户属性，所有功能面向接口，依赖下层实现.
接口抽象类 AbstratorUser
Java代码
1. UserInfo userInfo;    --用户属性 
2.  
3. //用户操作对象. 
4. Abstrator UserOperator getUserOperator() –用户操作对象信息，依赖下层 
5.  
6. //overwriter 
7. Speak(){ 
8.              getUserOperator ().Speak(); 
9. } 
10.  
11. //overwriter 
12. Walk(){ 
13.             getUserOperator ().Walk(); 
14. } 
15. //用户信息在初始的时候留给子类设置 
16. Void setUserInfo(UserInfo userInfo){ 
17.   This.userInfo=userInfo 
18. } 
19.  
20. //overwriter 
21. UserInfo getUserInfo(){ 
22.   Return userInfo; 
23. } 

[对业务逻辑的初步封装，蓝色部分是重写方法，而红色部分是需要依赖下层建筑的]

以上为设计阶段完成的，而下层建筑就交给开发工程师来完成，不同的开发工程师的水平和风格可能不一样，但是完全分离的方式使各模块[用户信息，用户操作]都能够正常运行，耦合为0. [这个代码更改的概率为0]

现在Action层代码更改为0,接口层和抽象层代码修改为0，那么当用户逻辑变的时候，只需要修改下层建筑就可以了!.

UserInfo为用户信息，这是一个实体类，其各对象的属性采用组合的方式来连接
Address,Account,Family.如果需要添加一些Friend等信息很方便，与其他模块不会有耦合.
UserOperator为用户操作对象，这是一个接口，依赖下层建筑.如果用户Speak的方式从中文变成英文了，只需要修改下层建筑就可以了.

这就是DDD，领域驱动开发,只依赖下层建筑,而下层建筑就是最简单的增删改查操作.也就是业务最需要变动的地方，领域驱动可以把一个项目分成一 个域，而这个域能够包含这个项目的所有信息，其实DDD并不算新的技术，他只是提供了一个概率，分析与设计的组合可以把业务逻辑理清，减少上层建筑的缺 陷，而下层建筑是可以随机换的，上层建筑一般是基本接口和抽象，只要业务逻辑没有分析出错，就不需要改动.而DDD把层分成两层，应用层和领域层，也是从 整体考虑，应用层调用领域层的接口，其实领域层也可以分层，他只是让系统的策划更简单，不用考虑那么多层，系统都是从简单到复杂，这相当于数据挖掘技术， 一张图很简单，再挖一下也很简单，再挖一下也很简单，应用不同的项目，不同的模块，基于接口和抽象的设计，并能从全局考虑就是DDD的思想.

现在来回答领域模型是什么:
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
现实中的人                                    User
人的属性                                         getUserInfo()
人说话                                           Opertator.Speak()
人走路                                           Operator.Walk()
如何寻找模型:
在业务专家和设计专家一些交流的时候，设计专家能够从业务专家的描述中抽取出实体及实体间的关系[泛化、依赖和关联，关联又分了一般关联、聚合、组合等等]