DDD步骤

设计领域模型的一般步骤：

1.  根据需求建立一个初步的领域模型，识别出一些明显的领域概念以及它们的关联，关联可以暂时没有方向但需要有（1：1，1：N，M：N）这些关系；可以用文字精确的没有歧义的描述出每个领域概念的涵义以及包含的主要信息；

2.  分析主要的软件应用程序功能，识别出主要的应用层的类；这样有助于及早发现哪些是应用层的职责，哪些是领域层的职责；

3.  进一步分析领域模型，识别出哪些是实体，哪些是值对象，哪些是领域服务；

4.  分析关联，通过对业务的更深入分析以及各种软件设计原则及性能方面的权衡，明确关联的方向或者去掉一些不需要的关联；

5.  找出聚合边界及聚合根，这是一件很有难度的事情；因为你在分析的过程中往往会碰到很多模棱两可的难以清晰判断的选择问题，所以，需要我们平时一些分析经验的积累才能找出正确的聚合根；

6.  为聚合根配备仓储，一般情况下是为一个聚合分配一个仓储，此时只要设计好仓储的接口即可；

7.  走查场景，确定我们设计的领域模型能够有效地解决业务需求；

8.  考虑如何创建领域实体或值对象，是通过工厂还是直接通过构造函数；

9.  停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方，比如思考一些对象应该通过关联导航得到还是应该从仓储获取？聚合设计的是否正确？考虑模型的性能怎样，等等；

================================================================================================

以DDD为开发模式的设计开发步骤可以是：
1）分析需求；

2）画出用例图，系统中各个角色如何使用系统，也包括外部系统如何使用系统，也包括系统中到某个时间点自动启动的某些功能（此时角色就是时间）；

  3）针对各个用例图，就知道了系统使用的各种业务场景，同时也明确了系统的边界，从而就明确了领域模型的边界；

4）在领域模型的边界内划分聚合，找出每个聚合的边界，找出边界内的聚合根，实体，值对象；这步是难点。这里一定不能混淆的一个概念是，领域建模不是以用户为中心的建模，而是以用户的需求为中心的建模。所以要努力寻找各种业务概念，切勿将所有行为都设计到User，Employee，Account，等对象上。而应该找出如Order，LeaveRecord，Payment，JobApplication，等业务概念。

5）如果是根据经典的DDD领域建模，我们可以接下来分析一些领域服务，领域服务用于协调多个领域对象之间的行为；

6）根据领域模型中的聚合根设计对应的仓储；这步完成就表示领域模型已经完成了。

7）对照前面的需求用例，检查领域模型是否都可以满足用例中提到的各种业务场景；

8）进一步分析领域模型，分析模型中哪些点是和特定系统相关的设计，哪些点可以进一步抽象出通用的领域模型，该通用领域模型可以满足此类相似系统的核心业务。比如积分系统中，可以抽象出“积分发放/消费”的模型。该模型可以在任何财务或积分系统中使用；

9）现在，可以让有经验的人检查一下你设计的领域模型了，也就是如果有可能就进行一下模型Review，确保在写代码之前，模型的正确性。

  10）对领域模型进行单元测试，单元测试的时候，如果只想测试业务逻辑，可以设计Stub的仓储；如果想和持久化一起测试，那可以编写真实的仓储，如果你是用Hibernate来做数据存储，可以在此时建立ORM映射文件和数据库表；写完后，编写测试用例进行单元测试；

11）最后实现你的UI层。但是为了让你的UI层可以不依赖于你的模型设计和测试，可以在UI层编写他自己需要的ViewModel，然后他在Web Form或Controller或View上只要访问ViewModel即可。等到你的领域模型完成并测试通过后，把领域模型的数据填充到ViewModel即可；