基于DDD项目的设计总结
2009-03-19 16:14
113 查看
一、为什么要使用领域模型
• 有助于团队创建一个业务部门与IT部门都能理解的通用模型,并用该模型来沟通业务需求、数据实体、过程模型。
• 模型是模块化、可扩展、易于维护的,同时设计还反映了业务模型。
• 提高了业务领域对象的可重用性和可测性。
二、领域的分层架构
在Eric Evans《领域驱动设计--软件核心复杂性应对之道》中对领域的分层架构如下:
• 用户界面(表现层):负责给用户展示信息,并解释用户命令。
• 应用层:该层协调应用程序的活动。不包括任何业务逻辑,不保存业务对象的状态,但能保存应用程序任务过程的状态。
• 领域层:这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。
• 基础设施层:对其它层来说,这一层是一个支持性的库。它提供层之间的信息传递,实现业务对象的持久化,包含对用户界面层的支持性库等。
三、如何创建领域模型
• 寻找概念类
• 将其绘制为UML类图中的类
• 添加关联和属性
四、领域模型的开发步骤
• 对领域进行建模
• 设计
• 开发
• 单元测试和集成测试
• 基于设计和开发来完善、重构领域模型
• 使用更新的领域模型重复上述步骤
五、实际项目设计
1、层次结构:
2、层次之间的交互
A、页面提交表单数据到Action,Action创建DTO对象并设置相应属性值为表单数据
B、Action传递DTO对象给Facade
C、Facade中套用ServiceTemplate事务模板以加入事务管理,在ServiceTemplate中根据具体业务调用Factory或Reposistory,分别create或者load出DomainModel对象
D、Facade传递DomainModel对象给Service
E、Service执行具体业务逻辑(调用DomainModel对象相应的业务方法)
F、Service调用Reposistory对状态已改变的DomainModel对象进行持久化操作(调用相应DAO)
注:
在Facade或Service中如果需要查询DomainModel对象中的属性值,调用DomainModel对象的getDataInfo()方法得到DataInfo对象,通过DataInfo对象查询所需数据,包括Service返回给Façade业务处理结果中所包含的业务数据。
3、对于DomainModel的设计
DomainModel基于贫血模型来设计。在Robbin《总结一下最近关于domain object以及相关的讨论》一文对于贫血模型领域的切分原则写到:
在该项目中DomainModel内的业务逻辑方法没有任何对DAO接口的依赖,如果需要对DomainModel进行持久化操作全部由Service调用Reposistory的store()方法进行处理,对DomainModel的持久化操作已全部封装于Reposistory中。DomainModel只提供改变自身状态的业务处理方法。
4、对DomainModel的访问原则
A、必须从领域模型的根部操作模型的各个属性
例如一个领域模型结构如下:
操作该领域模型的person属性只能通过modifyPerson()方法进行,而不能直接调用person对象的setter方法。
B、必须保持领域模型的完整性。最初由Factory构造一个模型的时候,就必须将其进行完整的初始化,而不是只构造一部分,然后在接下来的处理过程中逐步完善。
5、Factory和Reposistory的职责
Factory只负责领域模型对象的创建(从无到有);
Reposistory对持久化进行了封装,它操作的是已存在的领域模型对象(从数据库中读取数据or重新持久化到数据库)
6、项目待优化部分
在Service调用Reposistory的store()方法进行持久化操作时,如果某个业务仅对DomainModel的一部分属性进行了修改,在持久化到数据库中时仍然会将DomainModel的所有属性全部进行一次update操作。这样的数据库操作没有必要,只需对DomianModel中修改过的属性进行持久化操作即可。可以考虑在DomainModel上提供一个类似保存所有修改属性的列表,在Reposistory持久化时仅对该列表中的修改属性进行操作。
参考资料:
1、Eric Evans《领域驱动设计--软件核心复杂性应对之道》
2、Robbin《总结一下最近关于domain object以及相关的讨论》http://www.iteye.com/topic/11712 阅读更多
• 有助于团队创建一个业务部门与IT部门都能理解的通用模型,并用该模型来沟通业务需求、数据实体、过程模型。
• 模型是模块化、可扩展、易于维护的,同时设计还反映了业务模型。
• 提高了业务领域对象的可重用性和可测性。
二、领域的分层架构
在Eric Evans《领域驱动设计--软件核心复杂性应对之道》中对领域的分层架构如下:
• 用户界面(表现层):负责给用户展示信息,并解释用户命令。
• 应用层:该层协调应用程序的活动。不包括任何业务逻辑,不保存业务对象的状态,但能保存应用程序任务过程的状态。
• 领域层:这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。
• 基础设施层:对其它层来说,这一层是一个支持性的库。它提供层之间的信息传递,实现业务对象的持久化,包含对用户界面层的支持性库等。
三、如何创建领域模型
• 寻找概念类
• 将其绘制为UML类图中的类
• 添加关联和属性
四、领域模型的开发步骤
• 对领域进行建模
• 设计
• 开发
• 单元测试和集成测试
• 基于设计和开发来完善、重构领域模型
• 使用更新的领域模型重复上述步骤
五、实际项目设计
1、层次结构:
2、层次之间的交互
A、页面提交表单数据到Action,Action创建DTO对象并设置相应属性值为表单数据
B、Action传递DTO对象给Facade
C、Facade中套用ServiceTemplate事务模板以加入事务管理,在ServiceTemplate中根据具体业务调用Factory或Reposistory,分别create或者load出DomainModel对象
D、Facade传递DomainModel对象给Service
E、Service执行具体业务逻辑(调用DomainModel对象相应的业务方法)
F、Service调用Reposistory对状态已改变的DomainModel对象进行持久化操作(调用相应DAO)
注:
在Facade或Service中如果需要查询DomainModel对象中的属性值,调用DomainModel对象的getDataInfo()方法得到DataInfo对象,通过DataInfo对象查询所需数据,包括Service返回给Façade业务处理结果中所包含的业务数据。
3、对于DomainModel的设计
DomainModel基于贫血模型来设计。在Robbin《总结一下最近关于domain object以及相关的讨论》一文对于贫血模型领域的切分原则写到:
Rod Johnson提出原则是“case by case”,可重用度高的,和domain object状态密切关联的放在Item中,可重用度低的,和domain object状态没有密切关联的放在ItemManager中。
我提出的原则是:看业务方法是否显式的依赖持久化。
在该项目中DomainModel内的业务逻辑方法没有任何对DAO接口的依赖,如果需要对DomainModel进行持久化操作全部由Service调用Reposistory的store()方法进行处理,对DomainModel的持久化操作已全部封装于Reposistory中。DomainModel只提供改变自身状态的业务处理方法。
4、对DomainModel的访问原则
A、必须从领域模型的根部操作模型的各个属性
例如一个领域模型结构如下:
public class PersonDomainModel {
Person person;
Bank bank;
public void modifyPerson(String name, String age) {
this.person.setName(name);
this.person.setAge(age);
}
}
操作该领域模型的person属性只能通过modifyPerson()方法进行,而不能直接调用person对象的setter方法。
B、必须保持领域模型的完整性。最初由Factory构造一个模型的时候,就必须将其进行完整的初始化,而不是只构造一部分,然后在接下来的处理过程中逐步完善。
5、Factory和Reposistory的职责
Factory只负责领域模型对象的创建(从无到有);
Reposistory对持久化进行了封装,它操作的是已存在的领域模型对象(从数据库中读取数据or重新持久化到数据库)
6、项目待优化部分
在Service调用Reposistory的store()方法进行持久化操作时,如果某个业务仅对DomainModel的一部分属性进行了修改,在持久化到数据库中时仍然会将DomainModel的所有属性全部进行一次update操作。这样的数据库操作没有必要,只需对DomianModel中修改过的属性进行持久化操作即可。可以考虑在DomainModel上提供一个类似保存所有修改属性的列表,在Reposistory持久化时仅对该列表中的修改属性进行操作。
参考资料:
1、Eric Evans《领域驱动设计--软件核心复杂性应对之道》
2、Robbin《总结一下最近关于domain object以及相关的讨论》http://www.iteye.com/topic/11712 阅读更多
相关文章推荐
- 【基于WPF+OneNote+Oracle的中文图片识别系统阶段总结】之篇一:WPF常用知识以及本项目设计总结
- 【基于WPF+OneNote+Oracle的中文图片识别系统阶段总结】之篇一:WPF常用知识以及本项目设计总结
- 项目开发中的一些注意事项以及技巧总结 基于Repository模式设计项目架构—你可以参考的项目架构设计 Asp.Net Core中使用RSA加密 EF Core中的多对多映射如何实现? asp.net core下的如何给网站做安全设置 获取服务端https证书 Js异常捕获
- 项目架构设计总结:基于阿里云搭建的轻量级架构
- vue2.0---vue-router总结(项目基于vue-cli)
- (五)实际项目中分布式系统设计涉及算法总结
- 基于.NET平台的Windows编程实战(三)—— 项目的创建及主界面的设计
- WeText项目:一个基于.NET实现的DDD、CQRS与微服务架构的演示案例
- 基于性能的设计和sql调优培训的总结
- 艾伟:基于web信息管理系统的权限设计分析和总结
- 基于事件的监听,消息订阅设计模式的实现框架,ERP,OA,复杂,灵活多变的项目的福音
- 基于vue.js的直播项目设计
- jphone项目设计介绍(一个基于C++的应用程序框架以及软电话和日志服务器应用)
- [转] 效率优先 适度设计——网盟投放平台体验优化项目总结
- 基于DDD的.NET开发框架 - ABP分层设计
- 项目总结(一)试用期培养流程介绍及主要的表设计
- 海量服务实践──手 Q 游戏春节红包项目设计与总结(下篇)
- 应用Rational工具简化基于J2EE项目(五)架构与设计
- 基于SSL验证的Apache CXF客户端设计总结
- 权限项目总结(一)常用权限设计