谈领域驱动的设计

标签: 随笔文章 | 发表时间:2012-04-28 13:05 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
最近一直在学习领域驱动设计,发现领域驱动设计的核心仍然是传统的面向对象分析设计的思路,但是却可以很好的和现有的组件化架构,分层架构,SOA服务等相关内容更好的融合。对于传统的EA企业架构分析在分解到最底层的时候,很适合自然过渡到领域驱动设计的思路上来。另外对于现有的基于NoSQL数据库的信息系统开发,领域驱动设计更是必须具备的系统分析和建模思路。

领域在这里我更愿意将其理解为业务领域,领域的表现是一系列存在相关关联和依赖关系的业务实体对象表现出现的业务行为的一个合集。传统的用例驱动往往我们会先分析会有哪些业务行为和业务操作,再来分析这些行为操作的承载对象,如RUP中的实体类控制类等。领域驱动的方法则可能是尽快先找出核心的业务实体对象,再通过交互分析来分析对象应该展现出来的行为。

在解耦的层面我们看到两个层面的解耦,首先是业务操作和业务实体的解耦,这也是传统的SOA的一个思想,在领域建模里面可以看到分解为业务服务,实体对象和值对象等。第二个层面则是应用功能,服务能力,基础设施三层的解耦,在领域驱动设计的分层架构中则将其分解为了应用层,领域层,基础设施层。基础设施层提供资源层和持久化的能力,领域层提供业务服务能力,而应用层仅仅处理能力的协同,状态保存,服务的编排问题等。

领域驱动设计中领域层的构建可以是整个系统构建的核心,通过领域层的构建再拓展到持久化层和界面展现层。领域模型完全基于面向对象思路构建,因此完全可以兼顾底层是关系型数据库还是NoSQL数据库来持久化。而且领域模型的持久化好像专门就是为适合NoSQL数据库而设计。对于界面展现层相同的道理,领域层只是提供和暴露业务服务,具体业务服务如何交互,协同和展现并不是关键。

一个完整的领域层应该包括了实体对象,值对象,主域模型类,业务服务类几个关键的类。实体对象有唯一的标识符,需要持久化,对应现实中的业务对象,而值对象无唯一标识符,仅仅关注它拥有的一组属性。实体对象本身会表现出对应到行为,而值对象仅仅是属性的结合。在多个实体对象上层可能还要构建主域层对象,程度跨多个实体对象的操作组合。而对于业务服务仅仅是能力通过接口方式的暴露。一方面是实现应用层到领域层的协同,一方面是实现多个domain主域间的协同。

对于领域层,在大型系统构建过程中可以是首先进行全局的领域层建模在划分为多个domain域,形成业务组件或模块。也可以首先进行业务主体域的划分,然后再分解下去后识别每个业务主题域里面的实体对象和表现行为。组件划分思路需要引入到大型领域层的构建。即领域层也会组件化和模块化。业务服务即需要考虑模块内,也需要考虑模块间协同。在这里可以看到是领域层本身进行模块化后引入的,对业务服务的能力进行了扩展。

领域驱动设计让我们在分析和构建一个应用系统的时候,真正的转正核心矛盾,即领域对象和行为表现,而不是太多的关注基础设施和持久化机制,不去关心前台的展现层技术等。因为只有领域层这块在各种技术架构中是完全可以复用的,也是业务系统的核心。我们谈业务架构驱动应用架构,而业务架构核心内容就应该体现到应用架构的领域层模型中。

对于实体(Entities),值对象(Value objects),工厂(Factories),仓库(Repositories)和服务(Services)的关系再做一个理解如下。工厂(Factories)完成实体对象的实例化并通过服务接口传递到展现层面和应用层,而仓库(Repositories)则是和基础设施层接口,实现实例化对象后的持久化问题。

对于聚合,其核心即是多个实体对象是否是共同的生命周期存在,如果是的话则一定有一个聚合根,没有根存在了下面的子节点也将消亡。如客户,客户银行账户是聚合关系。订单,订购明细记录是聚合关系。这些虽然在存储的时候可能是多张数据表,但是在对象的管理上往往是当做一个完整业务实体对象在管理。

相关 [领域 设计] 推荐:

谈领域驱动的设计

- - 人月神话的BLOG
最近一直在学习领域驱动设计,发现领域驱动设计的核心仍然是传统的面向对象分析设计的思路,但是却可以很好的和现有的组件化架构,分层架构,SOA服务等相关内容更好的融合. 对于传统的EA企业架构分析在分解到最底层的时候,很适合自然过渡到领域驱动设计的思路上来. 另外对于现有的基于NoSQL数据库的信息系统开发,领域驱动设计更是必须具备的系统分析和建模思路.

领域驱动设计和实践

- - 博客园_知识库
  软件系统面向对象的设计思想可谓历史悠久,20世纪70年代的Smalltalk可以说是面向对象语言的经典,直到今天我们依然将这门语言视为面向对象语言的基础. 随着编程语言和技术的发展,各种语言特性层出不穷,面向对象是大部分语言的一个基本特性,像C++、Java、C#这样的静态语言,Ruby、Python这样的动态语言都是面向对象的语言.

领域驱动设计系列(1)通过现实例子显示领域驱动设计的威力

- - 博客园_知识库
  曾经参与过系统维护或是在现有系统中进行迭代开发的软件工程师们,你们是否有过这样的痛苦经历:当需要修改一个Bug的时候,面对一个类中成百上千行的代码,没有注释,千奇百怪的方法和变量名字,层层嵌套的方法调用,混乱不堪的结构,不要说准确找到Bug所在的位置,就是要清晰知道一段代码究竟是做了什么也非常困难.

Boticca 把 Etsy 模式带到高端全球设计领域

- Kofai - 36氪
今年年初,爱沙尼亚珠宝设计师 Krista Raak 在巴黎的一个小型艺术品市场出售手工刺绣项链,后来她的作品被 Boticca.com 创始人发现,然后受邀加入该公司的全球首饰市场,Raak 一直想把自己的作品走出街旁集市和精品店,于是欣然接受. 合作三个月之后,Raak 已经获得大约1万美元的销售额,她拿80%.

领域驱动设计和实践-转载

- - 人月神话的BLOG
引言(原文: http://www.kuqin.com/system-analysis/20110912/264696.html). 软件系统面向对象的设计思想可谓历史悠久,20世纪70年代的Smalltalk可以说是面向对象语言的经典,直到今天我们依然将这门语言视为面向对象语言的基础. 随着编程语言和技术的发展,各种语言特性层出不穷,面向对象是大部分语言的一个基本特性,像C++、Java、C#这样的静态语言,Ruby、Python这样的动态语言都是面向对象的语言.

浅谈微服务体系中的分层设计和领域划分

- - DockOne.io
看标题感觉这个东西很理论,比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点,软件体系知识显得很“湿”,似乎人人都有自己的认识,但又很少有人能说完整,有一点可以确定的是,如果你未来需要独立设计一个复杂的系统中台,并使之未来能快速应对各种需求变化的话,科学合理的领域划分和边界界定需要我们“处女座级”的坚持下去,这对防止人力失控、减少项目烂尾很有帮助.

【翻译】防腐层:面向领域驱动设计的更为稳健的系统集成方案

- - 博客园_首页
本文翻译自领域驱动设计官方网站的一篇实践性论文,原文题为《. IAnticorruption – A Domain-Driven Design Approach To More Robust Integration》,我觉得这篇论文写得很不错,实践性非常强,通过对一个真实项目的研究,并结合整个团队在项目实践上的经验,总结了领域驱动设计在系统集成方面的指导作用:通过防腐层的引入,改善现有的系统集成架构,并引导整个项目和团队实现可持续化发展.

谈领域服务

- - 人月神话的BLOG
对于跨系统和模块间的SOA服务识别和分析我前面文章谈的比较多,这块的SOA服务重点是实现跨系统和模块的业务交互和协同,而对于领域服务而言则更加关心的是对于单个系统或模块,其应该如何抽象领域对象并将其能力以粗粒度服务方式保留给应用层用. 在领域建模中的整体思路中,我们做两个层面的理解,其一是领域模型层重点是隔离传统的数据表并抽象为领域对象;而对于领域服务层重点是则将应用层和领域模型层解耦,模型层提供的能力是以领域服务的方式暴露到应用层使用的.

新领域的探索

- Fay - 人月神话的BLOG
在信息技术领域,任何新领域都是已有知识领域,已有技术和研究成果的进一步组合和创新,新领域一分解到底层你会发现全是已有技术,方法和工具. 这些很可能都是我们熟悉的内容,而新领域仅仅是对已有知识和技术的进一步组合,形成一套完整的方法和技术来解决新的问题. 当接触一个新领域的时候,首先是大量的阅读,在一开始没有机会实践的时候,那只有先补充和学习基础的理论,了解新领域的知识体系和结构,了解新领域所涉及到得关键技术.

Viddy:视频领域的Instagram?

- - Tech2IPO
Instagram刚被Facebook以 十亿美元的价格收购,成为照片分享领域的传奇. 与此同时,以视频领域的Instagram而著称的 Viddy在近日也冲上iPhone 免费应用榜首的位置. Business Insider甚至撰文建议 Google收购Viddy,从而在移动视频领域占据先机.