0
点赞
收藏
分享

微信扫一扫

DDD(领域驱动设计)总结

西特张 2021-10-15 阅读 98
日记本DDD

原文总结:https://www.cnblogs.com/firstdream/p/8669611.html

基本概念:

  领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名:领域驱动设计—软件核心复杂性应对之道)一书。,书中提出了“领域驱动设计(简称 ddd)”的概念。

         领域驱动设计一般分为两个阶段:

1.   以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具,在不断交流的过程中发现和挖出一些主要的领域概念,然后将这些概念设计成一个领域模型;

2.   由领域模型驱动软件设计,用代码来表现该领域模型。领域需求的最初细节,在功能层面通过领域专家的讨论得出。

       领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点:

1.领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是有边界的,只反应了我们在领域内所关注的部分;

2.领域模型只反映业务,和任何技术实现无关;领域模型不仅能反映领域中的一些实体概念,如货物,书本,应聘记录,地址,等;还能反映领域中的一些过程概念,如资金转账,等;

3.领域模型确保了我们的软件的业务逻辑都在一个模型中,都在一个地方;这样对提高软件的可维护性,业务可理解性以及可重用性方面都有很好的帮助;

4.领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造;

5.领域模型贯穿软件分析、设计,以及开发的整个过程;领域专家、设计人员、开发人员通过领域模型进行交流,彼此共享知识与信息;因为大家面向的都是同一个模型,所以可以防止需求走样,可以让软件设计开发人员做出来的软件真正满足需求;

6.要建立正确的领域模型并不简单,需要领域专家、设计、开发人员积极沟通共同努力,然后才能使大家对领域的认识不断深入,从而不断细化和完善领域模型;

7.为了让领域模型看的见,我们需要用一些方法来表示它;图是表达领域模型最常用的方式,但不是唯一的表达方式,代码或文字描述也能表达领域模型;

8.领域模型是整个软件的核心,是软件中最有价值和最具竞争力的部分;设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化;


领域驱动设计中的一些基本概念:

开发人员将实体当成了orm意义上的实体,而不是业务所有和业务定义的领域对象。在一些实现中采用了transaction script风格的架构,使用贫血的领域模型。这种认识上的混乱,在领域驱动架构中,不愿意在领域对象中加入业务逻辑而导致贫血的领域模型,同时还可能使混乱的服务对象激增。


业务规则

5. 基于聚合的以上概念,我们可以推论出从数据库查询时的单元也是以聚合为一个单元,也就是说我们不能直接查询聚合内部的某个非根的对象;

  6. 聚合内部的对象可以保持对其他聚合根的引用;

  7. 删除一个聚合根时必须同时删除该聚合内的所有相关对象,因为他们都同属于一个聚合,是一个完整的概念。


如何识别聚合?

聚合中的对象关系是内聚的,即这些对象之间必须保持一个固定规则,固定规则是指在数据变化时必须保持不变的一致性规则。

        当我们在修改一个聚合时,我们必须在事务级别确保整个聚合内的所有对象满足这个固定规则。

作为一条建议,聚合尽量不要太大,否则即便能够做到在事务级别保持聚合的业务规则完整性,也可能会带来一定的性能问题。

        有分析报告显示,通常在大部分领域模型中,有70%的聚合通常只有一个实体,即聚合根,该实体内部没有包含其他实体,只包含一些值对象;另外30%的聚合中,基本上也只包含两到三个实体。这意味着大部分的聚合都只是一个实体,该实体同时也是聚合根。


如何识别聚合根?

  如果一个聚合只有一个实体,那么这个实体就是聚合根;如果有多个实体,可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。

       并不是所有的实体都是聚集根,但只有实体才能成为聚集根。


数据库和应用之间的契约。

        repository:位于领域层,面向aggregation root。repository是一个独立的抽象,使用领域的通用语言,它与dao进行交互,并使用领域理解的语言提供对领域模型的数据访问服务的“业务接口”。

dao方法是细粒度的,更接近数据库,而repository方法的粒度粗一些,而且更接近领域。领域对象应该只依赖于repository接口。客户端应该始终调用领域对象,领域对象再调用dao将数据持久化到数据 存储中。

处理领域对象之间的依赖关系(比如实体及其repository之间的依赖关系)是开发人员经常遇到的典型问题。解决这个问题通 常的设计方案是让服务类或外观类直接调用repository,在调用repository的时候返回实体对象给客户端。


开发人员来说创建不应该存在的服务相当容易;要么在服务中包含了本应存在于领域对象中的领域逻辑,要么扮演了缺失的领域对象角色,而这些领域对象并没有作为模型的一部分去创建。



应用程序事件大致可以分为三类:系统事件、应用事件和领域事件。领域事件的触发点在领域模型(domain model)中。它的作用是将领域对象从对repository或service的依赖中解脱出来,避免让领域对象对这些设施产生直接依赖。它的做法就是当领域对象的业务方法需要依赖到这些对象时就发出一个事件,这个事件会被相应的对象监听到并做出处理。

        通过使用领域事件,我们可以实现领域模型对象状态的异步更新、外部系统接口的委托调用,以及通过事件派发机制实现系统集成。另外,领域事件本身具有自描述性。它不仅能够表述系统发生了什么事情,而且还能够描述发生事件的动机。

         domain事件也用表进行存储。


数据结构减少网络通信并简化调用接口。


架构设计

领域驱动架构

        eric  evans的“领域驱动设计- 应对软件的复杂性“一书中描述和解释了建议的n层架构高层次的图:

user interface:

        该层包含与其他系统/客户进行交互的接口与通信设施,在多数应用里,该层可能提供包括web services、rmi或rest等在内的一种或多种通信接口。该层主要由facade、dto和assembler三类组件构成,三类组件均是典型的j2ee模式。

dto的作用最初主要是以粗粒度的数据结构减少网络通信并简化调用接口。在领域驱动设计中,采用dto模型,可以起到隐藏领域细节,帮助实现独立封闭的领域模型的作用。

        dto与领域对象之间的相互转换工作多由assembler承担,也有一些系统使用反射机制自动实现dto与领域对象之间的相互转换,如apache common beanutils。

        facade的用意在于为远程客户端提供粗粒度的调用接口。facade本身不处理任何的业务逻辑,它的主要工作就是将一个用户请求委派给一个或多个service进行处理,同时借助assembler将service传入或传出的领域对象转化为dto进行传输。


application:

         application层中主要组件就是service。这里需要注意的是,service的组织粒度和接口设计依据与传统transaction script风格的service是一致的,但是两者的实现却有质的区别。

transaction script(事务脚本)的核心是过程,通过过程的调用来组织业务逻辑,业务逻辑在服务(service)层进行处理。大部分业务应用都可以被看成一系列事务。

transaction script的特点是简单容易理解,面向过程设计。  如果应用相对简单,在应用的生命周期里不会有基础设施技术的改变,尤其是业务逻辑很少会变动,采用transaction script风格简单自然,性能良好,容易理解。

transaction script的缺点在于,对于复杂的业务逻辑难以保持良好的设计,事务之间的冗余代码不断增多。应用架构容易出现“胖服务层”和“贫血的领域模型”。同时,service层积聚越来越多的业务逻辑,导致可维护性和扩展性变差

领域模型属于面向对象设计,领域模型具备自己的属性行为和状态,领域对象元素之间通过聚合配合解决实际业务应用。可复用,可维护,易扩展,可以采用合适的设计模型进行详细设计。缺点是相对复杂,要求设计人员有良好的抽象能力。

transactionscript风格业务逻辑主要在service中实现,而在领域驱动设计的架构里,service只负责协调并委派业务逻辑给领域对象进行处理。因此,我们可以考察这一点来识别系统是transaction script架构还是domain model架构。在实践中,设计良好的领域设计架构在开发过程中也容易向transaction script架构演变。


domain:

domain层是整个系统的核心层,该层维护一个使用面向对象技术实现的领域模型,几乎全部的业务逻辑会在该层实现。domain层包含entity(实体)、valueobject(值对象)、domain event(领域事件)和repository(仓储)等多种重要的领域组件。


infrastructure:

        infrastructure(基础设施层)为interfaces、application和domain三层提供支撑。所有与具体平台、框架相关的实现会在infrastructure中提供,避免三层特别是domain层掺杂进这些实现,从而“污染”领域模型。infrastructure中最常见的一类设施是对象持久化的具体实现。


架构设计

层(layers)被视为构成应用或服务的水平堆叠的一组逻辑上的组件。它们帮助区分完成不同任务的组件,提供一个最大化复用和可维护性的设计。简言之,是关于在架构方面应用关注点分离的原则。         在传统的多层架构中,每个解决方案的组件必须分隔到不同的层。每层的组件必须内聚而且有大约相同的抽象级别。每个一级层应该和其他的一级层松耦合。

        从最底层的抽象级别看,例如第1层。这是系统的基础层。这些抽象的步骤是一步一步的最后到最顶层。

        多层应用的关键在于对依赖的管理。传统的多层架构,层内的组件只能和同级或者低级层的组件交互。这有利于减少不同层内组件的依赖。通常有两种多层架构的设计方法:严格和灵活的。          *   “严格的层设计”限定层内的组件只能和同一层、或者下一层的组件通信。即第n层只能和第n-1层交互,n-1层只能和n-2层交互,等等。

         *  “灵活的层设计”允许层内的组件和任何低级别层交互。这种设计中,第n层可以和n-1,n-2层交互。

        这种设计由于不需要对其他层进行重复的调用,从而可以提高性能。然而,这种设计不提供层之间的同层隔离级别,使得它难以在不影响多个高级层的时候替换一个低级的层。

        由于层之间是通过定义明确的接口进行交互这一事实,很容易为各层添加替代的实现(例如 mock  and stubs)。

         因为高层的组件只能和底层的交互,在单独的组件上进行测试是很容易的。

使用层的好处  -  功能容易确定位置,解决方案也就容易维护。层内高内聚,层间松耦合使得维护/组合层更容易。 -  其他的解决方案可以重用由不同层暴露的功能。 -  当项目按逻辑分层时,分布式的部署更容易实现。 -  把层分布到不同的物理层可以提高可伸缩性;然后这一步应该进行仔细的评估,因为可能对性能带来负面影响。


面向领域架构的分层:

        在面向领域架构中,关键是要清楚界定和分离领域模型层和其余的层。


项目管理)和xp(适用于软件开发目标)方法对处理ddd实施项目。敏捷方法注重于交付商业价值,而ddd侧重于结合软件系统和业务模型。此 外,就ddd迭代的特性来说,scrum或dsdm这样的敏捷方法对项目管理来说也是更好的框架。

ddd迭代周期的项目管理模型如图所示。

本图根据《domain driven design and development in practice》一文中插图进行了部分修改。

  领域建模结束时可以开始领域驱动设计。关于如何开始实现领域对象模型,ramnivas laddad推荐如下的步骤。他强调要更侧重于领域模型中的领域对象,而不是服务。

       *   从领域实体和领域逻辑开始。

       *   不要一开始就从服务层开始,只添加那些逻辑不属于任何领域实体或值对象的服务。

*   利用通用语言、契约式设计(dbc)、自动化测试、  ci和重构,使实现尽可能地与领域模型紧密结合。


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

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

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

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

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

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

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

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

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

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

         领域建模是一个不断重构,持续完善模型的过程,大家会在讨论中将变化的部分反映到模型中,从而是模型不断细化并朝正确的方向走。


从设计和实现的角度来看,典型的ddd框架应该支持以下特征。

       *   应该是一个以pojo为基础的架构。

       *   应该支持使用ddd概念的业务领域模型的设计和实现。

       *   应该支持像依赖注入(di)和面向方向编程(aop)这些概念的开箱即用。

*   与单元测试框架整合。

       *   与其它java/java ee框架进行良好的集成,比如jpa、hibernate、toplink等。


一些反模式:

       *   贫血的领域对象

       *   重复的dao

       *   肥服务层:服务类在这里最终会包含所有的业务逻辑。

       *   依恋情结(feature envy):函数对某个类的兴趣高过对自己所处类的兴趣。


软件开发领域的知识,相反强调的是具有领域中的相关知识。领域需求在相互讨论中不断得到细化,还有可能在开发过程出现需求的反复或变更,这都要求领域模型的建立完善是一个反复重构的过程。敏捷开发是一种应对快速变化的需求的一种软件开发能力。强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。故采用敏捷开发有利于领域模型的建立完善,以更能符合用户的实际需求。

      关于领域模型分析存在有多种分析方法。也许并不是能经常能有机会去实践这些分析方法或分析领域模型。但关于领域驱动架构的理解,有助于帮助我们去理解领域驱动的设计,实现一些高内聚、低耦合的代码实现。


2.  领域服务建模

建立和识别领域服务也比较容易出错。通常的ssh分层架构与领域驱动架构相近,而ssh架构开发更容易导致transaction script架构而非领域驱动架构。在ssh分层架构上,开发人员更容易建立”贫血”模型,而在service里实现业务逻辑。而ddd强调“充血模型”,“薄”service层。建立领域服务需要识别出领域业务逻辑,并将业务实现到领域模型中。一方面,业务需求充满着变化,在开发过程中难以把握。当业务不明需求不清时,“贫血模型”就更容易被人接受。另一方面,在构建领域模型时,orm映射显示十分重要并且也非常复杂,包括类继承体系与数据库的映射,抓取策略和缓存管理在内的一系列问题等.“贫血模型”有时会简化这种映射关系,同时,在处理对象依赖关系上显得更加灵活性。而领域模型强调了领域边界,对领域对象的访问总是通过聚合根开始,在有时候,模型的某些遍历会带来更大的性能和稳定性上的问题。而解决这些问题时,又常常会从实效性上出发而牺牲模型个别的清晰性和纯洁性。


3.领域对象、领域服务以及repository之间的互相依赖

在实际开发中,开发人员会经常需要处理领域对象之间的依赖关系,以及领域对象与repository间的依赖。通常可能的方案是让service或façade直接调用repository,从而获得返回的领域对象。这种方式导致各层间的依赖,通常我们应该考虑解耦这种依赖。当前实现组件解耦常用的技术无非是:控制反转(ioc)、依赖注入(di)、面向方面编程(aop)以及分布式服务接口。因此,解决依赖的一种思路利用di或aop将repository和服务注入到领域对象中。spring框架提供了相关的机制。在spring环境中,利用spring实例化对象,注入依赖,将服务、repository等领域对象联系起来。

举报

相关推荐

0 条评论