传统三层向DDD的转变：
- 实体见引入合理的关联。
- 根据需要引入聚合。
- 将DAL命名的类换成Repository命名。
- 将BAL命名的类换成Service。
- 将BAL中的一些职责重构到Domain中。
- 引入Applicaiton层。
- 根据需要引入ViewModel和Mapper。
- 根据需要引入工作单元。
- 小心ORM工具提供的主键映射功能。
- 推荐引入IoC容器。
- 推荐引入AOP。
以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即可；