DDD & DDDLib在恒拓开源的发展历程与推广经验

标签: ddd dddlib 开源 | 发表时间:2014-01-01 17:52 | 作者:
出处:http://kb.cnblogs.com/

  领域驱动设计(DDD)的概念源于2004年著名建模专家Eric Evans发表的书籍:《Domain-Driven Design – Tackling Complexity in the Heart of Software》 中文译名:领域驱动设计—软件核心复杂性应对之道 ,池建强在2011年发表的一篇文章《 领域驱动设计和实践》中是这样形容DDD的:

领域驱动设计事实上是针对OOAD的一个扩展和延伸,DDD基于面向对象分析与设计技术,对技术架构进行了分层规划,同时对每个类进行了策略和类型的划分。

  本文主要介绍为什么我们在恒拓开源内部推广DDD,我们如何通过开发  DDDLib 和  Koala 等工具来完善这一过程,推广过程中遇到了哪些问题,以及我们如何解决这一问题。

   为什么选择DDD

  传统的模式的最大优点在于开发人员非常熟悉,开发成本低,但它也有一些问题:

  采用DDD开发模式之前,传统的开发模型是最流行的Model-Dao-Service-UI开发模型,通常是基于事务脚本(Transaction Script)和表模块(Table Module)模式的实现,这种模式通常是先设计表,再建模,实现容易依赖特定的表的一些特性,如存储过程。基于表的设计模式容易带来以下几个问题:

  • 业务建模完全是表的复制,无法真实反映业务。
  • 核心业务分散在各个地方,非常危险,修改扩展难,且难以阅读。

  这种开发模式适合一些需求小,后续维护扩展需求小的中小型项目,但在大型企业级系统或产品,扩展维护或需求变量非常多的情况下,缺点也非常明显。

  相对而言,DDD则有以下四点好处:

  1、面向对象,模型真实反映业务现实:使用DDD领域驱动设计,模型通常是业务的真实反映,业务集中在领域而不是分散在各Service中,有利于对业务的理解。

  2、使用领域统一建模语言:有利于业务沟通与建模: DDD倡导先对业务建模,而非关注表或脚本的设计;在建模过程中,由于领域本身是对真实业务的反映与建模,因此与业务专家更容易沟通,打破技术与业务的沟通隔阂。

  3、可重用性高:DDD中,领域层为核心,每个领域对象都是一个相对完整的内聚的业务对象描述,所以可以形成直接的复用。基于领域建模的设计,并不会依赖特定的数据库及特性,模型是可以完全重用且没有技术上的冲突。

  4、业务越复杂,DDD的优势越明显:领域模型采用OO设计,通过将职责分配到相应的模型对象或Service,可以很好的组织业务逻辑,当业务变得复杂时,领域模型显出巨大的优势。

   DDDLib登场

  DDD本质上是一种思想,并不是新技术。在恒拓开源,由我们的杨宇老师和陈操总共同创作的DDDLib库,是对DDD思想的核心支持与实现。

  DDDLib是一整套支持DDD思想实现的类库,DDDLib下还是使用的 Hibernate、JPA或MyBatis、noSQL等技术为实现。

  如同DDD所要求样,使用DDDLib 的项目分层图为:

  • 用户界面/展现层
    • 用于向用户展现信息,处理用户在界面上的请求,比如struts,tapestry,springMVC等页面框架。
  • 应用层
    • 用来处理应用的活动,不包含领域中的业务逻辑。
    • 应用层可以用来处理一些与领域概念无关的拦截性质的工作,比如日志,事务等。此外,应用层也可以用来处理一些既不属于展现层,也不属于领域层,而是属于目前应用相关的一些服务。比如资金转账的业务的读取输入功能(读取输入不是转账的核心业务含义)。
  • 领域层
    • 此层是DDD的核心:领域对象,领域服务,仓储接口均位于此层。
    • 领域的信息,是业务软件的核心所在。
    • 需要保留业务对象的状态,对业务对象及其状态持久化的操作交给基础设施层。
    • 领域层应该遵从以下原则:除非业务发生变化,否则其他任何变化均不应该影响到领域层。这些其他变化包括:不同的展现框架,不同的页面展现内容,是否要分页,是否支持手机客户端,是否公开WebService,是否提供OpenAPI等等。
  • 基础设施层
    • 此层作为其他层次的支撑,可以为领域层的持久化提供支持,当领域层或应用层有特殊的业务或应用需求(发送短信等)时,它们会定义需求接口,然后在基础设施层中实现这个接口,满足特定的业务或应用需求。

  DDDLib的核心实现如下:

  上图就是使用 DDDLib 项目的整体技术架构图,也表明了DDDLib的整体原则:

  1. 领域层是业务核心,这一层不依赖任何特定的技术框架,保证它的业务纯洁性。DDDLib中的领域层只依赖JDK、DDDLib的Domain库以及仓储接口及其它自定义接口。
  2. 使用仓储和查询通道作为与存储介质相关的操作接口,隔离对特定数据库技术或存储介质的依赖。
  3. 提供多种不同的IoC容器实现及InstanceFactory实例工厂,隔离对特定IOC 技术的依赖。
  4. 领域层包括值对象、领域对象以及领域服务三个要素,领域层不是数据库操作层而是业务建模层。许多开发者在使用的过程中,最终还是把领域层作为数据库操作层来使用,对实体的方法也是以数据库的操作行为为标准 ,如查询,新增,删除一个实体,最终依然回归到以数据库为中心的方向去了,这是需要避免的。
  5. 改变以数据库为中心的核心是意识到业务行为才是核心,数据库存储是支撑。意识到数据库是支撑非常关键,业务上的任何行为,在系统中最终需要存储记录,数据库存储是对业务实现的支撑,也可以使用文件,缓存或云空间等其它存储介质。想像一下,使用数据库进行设计的项目,最终就限定了存储介质为特定的数据库,如果下一次需要更换为云空间或缓存等其它存储形式,就会发现整个系统需要重新设计开发,但使用DDDLib,只需更换仓储实现,提供一个云空间的实现就行了,核心业务逻辑完全不需要变动与修改。

  DDDLib在实现过程中也经历了内部的不少争议,经过很多次的讨论和打磨形成了现在的格局。在下面的部分,我将介绍DDDLib在几个重要组件上的实现细节。

   DDDLib仓储的实现

  从DDDLib 1.0到3.5版本,仓储实现历经几个阶段,分别是:

  1. 给每个领域对象定义一个仓储接口及一个仓储实现。

    这种仓储实现非常受争议,开发人员并不认可这种方式,仓储接口及实现非常多,一方面导致项目类太多,并且也带来编码的重复操作。

  2. 与spring data整合,给每个领域对象定义仓储接口,无须定义实现。这种模式对前面的模式有了优化,只定义接口不定义实现,但是spring data这种依赖方法名,参数来进行查询的模式,针对一些复杂的查询,难以胜任。
  3. 提供默认的hibernate及JPA的通用仓储接口。

    为每个仓储定义一个接口,这种模式慢慢的不被接受,使用spring data带来的优化方案,也有非常多的问题,后面根据JPA的实体管理思路,于是形成了通用仓储接口及不同技术实现的思路,定义一个通用的仓储接口,包括通用的增删改查数据库行为。

  4. 支持MyBatis的通用仓储接口

    DDDLib的JPA及hibernate仓储实现,这个方案是一个较佳的方案,所有领域实体使用通用的仓储,避免了大量重复代码,但DDDLib一直是基于Hibernate/JPA提供的实现与技术支持,在项目的使用过程中,经常会遇到不适合使用Hibernate/JPA模式的项目,对MyBatis的需求也非常大,这种情况下,Koala团队定义实现了MyBatis的仓储实现,并保证其与JPA/Hibernate模式下API的一致性。

   DDDLib中的DTO

  DTO,数据传输对象,领域对象虽然有数据(属性),但是领域对象上面还带有操作,在某些场合不适合进行传输,有些时候传输还需要序列化。但并不是所有的领域对象属性都可以暴露,而且有些属性可能要合并,可能要分解,之后才有利于前端的使用。于是就有了专门用来传输数据的DTO,只有属性,没有操作,必要的时候加上序列化标记,实现远程调用。

  这是DDD中DTO的作用,但是DTO同时也带来了实体与DTO的转换性能问题,在大数据量下尤其明显。

   DDDLib中的数据库支撑行为类

  在DDDLib实现中,提供了Repository以及QueryChannelService两个接口,分别使用在领域层以及应用层,都是对数据库的操作接口。

   SQL/HQL/JPQL写在哪

  在使用DDDLib的过程中,不同的持久层框架的SQL语言不一样,比如MyBatis使用的是SQL,Hibernate使用的是 HQL,JPA下使用的是JPQL。

  这些语句写在哪儿在公司也经历过一番争议与变更,历史如下:

  1、写在代码中

public static Resource newResource(String name,String identifier,String level,String menuIcon){
  Resource resource = null;
  List<Resource> resources = Resource.getRepository().find("select r from Resource r where r.name = ? " + "and r.identifier = ?", new Object[]{name,identifier}, Resource.class);
  ...
}

  这个非常容易理解:哪里要查询,哪里写SQL,这种模式是公司最初的使用方式,优缺点也非常明显。优点是直观,缺点则是,DDDLib倡导隔离特定技术,那这些语句写在写到代码中,意味着领域层中依赖了特定的技术语句,违背了DDDLib的目标。

  2、以@NamedQuery注解写在类上

@Entity
@NamedQuery(name="findAllEmployeesByFirstName",queryString="SELECT OBJECT(emp) FROM Employee emp WHERE emp.firstName = 'John'")
public class Employee implements Serializable {
  ...
}

  在Koala产品出现以前,DDDLib支持Hibernate以及JPA,这两种模式都支持@NamedQuery这种注解。曾经有人提议过这种方式,但并没有解决上面的问题,反而带来难以阅读的问题。

  3、以命名查询+xml实现

/**
* 判断一个资源是否有子资源
*/
public static boolean hasChildByParent(Long parentId) {
  return !Resource.findByNamedQuery("hasChildByParent", new Object[] { parentId }, Resource.class).isEmpty();
}

  在对应的 XML 配置中定义:

<named-query name="hasChildByParent">
<query>
select distinct m.id from ResourceLineAssignment m where m.parent.id=?
</query>
</named-query>  

  Koala团队后期定制了我们的方式,使用命名查询+xml配置方式来实现,并且基于这种方式,提供了MyBatis协议的支持实现,获得了一定的认可。

  使用这种方式,领域层的代码中不会出现特定的技术语句,解决了上述问题,不同的技术实现下不同的xml配置这种模式是可以接受的。

  但这种模式也仍有一些问题,包括:

  a) 动态条件查询不支持。一些查询的条件是动态的,这种模式下的HQL/JPQL是不支持的,但由于通常动态条件查询不属于业务核心,而是应用需求是在应用层,因此暂时仍然可以接受。

  b) 扩展其它存储介质的问题。Hibernate/JPA/MyBatis是常用的持久层框架,但是现在越来越多的出现诸如NoSQL、云存储等非关系型存储,使用这种模式来匹配这些存储,当前没有现成的解决方案

  4、不使用语句,而使用QueryCriterion

  DDDLib中提供了QueryCriterion这种查询机制,以期望做到隔离特定持久层框架的影响。很可惜,早期在恒拓推广使用 DDDLib 时,没有提及这种实现,因此恒拓的DDD一直未使用此方案。

  这种方式对于MyBatis难以支持,对于NoSQL、云存储等其它存储介质同样没有现成的解决方案。

  DDDLib最终使用了第三种方案。

  JPA下的写法:

  MyBatis下的写法:

  推广DDD遇到的挑战

  上面阐述了传统开发模式的一些问题,但是从另一个角度来说,传统的开发模式也有着它的优点:

  1. 使用成本低:基于传统开发方法,使用SSH等框架,基本上所有的开发人员都没有上手代价,立马可以参与开发。
  2. 开发速度快:传统模式的开发速度也快,尤其使用一些快速开发框架,开发一些简单业务的项目,是比较合适的。
  3. 在实际项目的开发中,传统模势的缺点并不明显,国内大部分项目只注重实际页面效果,至于设计的好坏,维护扩展的难易度并没有被重视。

  基于这些理解,在公司层面推广使用DDD思想存一些难点与阻碍,尤其是公司早期一些项目,使用DDD的所带来的优势并不明显,反而前期会带来使用成本。

  另一方面,对大部分开发人员来说,传统的模式更容易接受和习惯,表->DAO->Services->UI这种非常简单,基本没有学习成本。推广使用DDD则不一样,虽然技术上并没有任何创新,使用的还是Hibernate、Struts、Spring这些常用的技术,但关键是编码的思想不一样。DDD的要点,领域对象,领域服务,查询通道这些让开发人员理解并熟悉这种编码风格,也是个不小的挑战,推广初期经常会遇到开发人员对这些理念的质疑。

  另外,虽然DDD倡导先对领域进行分析建模,编写领域方法等核心,再考虑表的设计实现,但在实际的开发过程中,受以往的模式影响,就算使用了DDD模式,开发人员经常还是会用传统方式开发,对新模式无法理解,如:

  • 开发人员还是先设计表,再根据表设计领域对象。许多项目依然还是对实体进行增删改查,于是出现DTO与实体属性一模一样的情况。开发人员对DTO的存在的必要性无法理解。
  • 在传统的模式中,操作数据库的基本上属于Dao的责任。DDDLib提供了两个数据查询通道,开发人员对于哪些需要使用仓储,哪些需要使用查询通道不能清晰理解。
  • DDDLib提供了值对象,领域对象,领域服务来将领域与值进行分离,但是在实际的项目中,许多开发人员在项目使用领域对象,然后直接针对领域对象增删改查,很少真正使用到值对象、领域服务、聚合、工厂这些要素。

  以上种种让 DDD 又变成传统方式,这又进一步让开发人员感觉DDD与传统模式没有本质区别,于是加剧了开发人员对使用 DDD 的疑问。

   如何解决这些问题

  • 在公司内部推广宣传DDD&DDDLib

    DDD更多的是理念,技术细节和传统的方式没有区别,更多的是要让开发人员在理念上转变过来,因此推广DDD&DDDLib及其理念非常重要。不理解DDD思想理念来使用DDD,最终非常容易造成难以使用,这有什么用,或为什么要用这样的感觉。

  • 定期进行DDD在技术上的交流与探讨

    如前文所述,DDDLib的一些技术实现细节非常有争议性,因此我们会定期召集有想法的人员,不断讨论,收集使用者的意见,不断的修正优化实现。

    对于有争议的技术,也通过讨论,集思广益,找到最佳的实现方式。

  • 制定最佳编码实践,指导DDD方式的编码

    考虑到开发人员从传统模式转变到DDDLib编码风格的转变及学习成本问题,通常公司的架构部都会编写一个最佳DEMO,示例大家如何编写代码,理解查询通道,值对象,DTO,仓储,聚合等的实现与细节,帮助开发人员正确编写。

  • 通过真实项目逐步让大家认识到DDD的优点

    在一些项目上,使用 DDD 并没有实际的优点,只有在业务复杂,需要不断迭代的如产品这样的项目,才比较适合 DDD。我们通常会拿真实的项目中的代码来示例说明使用DDD的好处。

  • 开发一套基于DDD思想的开发平台,辅助更容易使用DDD编码

    在使用了较长的 DDDLib 之后,恒拓也推出了基于它的思想的Koala开发平台,借助这个开发平台,能更容易让开发者上手使用DDD。

   总结

  到目前,公司的大部分项目已经在使用DDDLib&Koala平台来实现。开发人员慢慢接受了这种思想,并且有许多人在DDDLib实现上提出了自己的意见与想法,包括仓储没有native SQL支持,NoSQL如何实现,DTO是否有必要,没有体现聚合,领域层是否可使用工厂,父实体需不需要基本属性(创建时间,创建者)等。

  接下来,我们计划在以下方面继续展开工作:

  1) 完善支持技术细节

  包括对NoSQL的仓储实现的支持,较好的支持非Spring IOC等,技术细节上仍然需要优化。

  2) 制定更为优化的DDDLib标准规范

  包括仓储,查询通道,聚合等理念,为它们提供更为优化的技术实现标准,更好的支持DDD设计。

  3) 完善基于DDDLib的Koala开发平台

  进一步完善 Koala开发平台,更好的支持DDD&DDDLib理念的实现。

  4) 推广DDD理念

  公司借助Koala这个开源平台,以让更多的人尝试并加入到使用 DDD或 DDDLib,推动国内做出更优秀的应用

   相关资料

   作者介绍

  刘林,恒拓开源架构师,对技术非常热爱与执着,关注开源技术及开源的解决方案,信奉并参与开源。在Java开发领域有一定的经验积累。参与并主导过一些开源项目的成功实施。现专注于Koala开源平台的开发。

相关 [ddd dddlib 开源] 推荐:

DDD & DDDLib在恒拓开源的发展历程与推广经验

- - 博客园_知识库
  领域驱动设计(DDD)的概念源于2004年著名建模专家Eric Evans发表的书籍:《Domain-Driven Design – Tackling Complexity in the Heart of Software》 (中文译名:领域驱动设计—软件核心复杂性应对之道 ),池建强在2011年发表的一篇文章《 领域驱动设计和实践》中是这样形容DDD的:.

基于DDD的微服务架构设计

- - ITeye博客
DDD领域驱动设计(DDD:Domain-Driven Design).     现有的架构设计实在受不了,业务的反反复复地变化,导致代码圈复杂度之深让人恐惧. 之前的微服务架构经验让我更加彻底点,采用DDD领域驱动设计进行整个改变.     随着经过几个月的努力,确实慢慢地体会到ddd的架构设计的优势,聚合根设计能够协助我们整个服务改造,开发起来越来越迅速.

为什么在做微服务设计的时候需要DDD?

- - DockOne.io
记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢. 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性. 但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可.

结合电商支付业务一文搞懂 DDD

- - IT瘾-dev
作者范钢,曾任航天信息首席架构师,《大话重构》一书的作者. 本文结合电商支付场景详细描述了领域驱动模型的实际应用. 2004 年,软件大师 Eric Evans 的不朽著作《领域驱动设计:软件核心复杂性应对之道》面世,从书名可以看出,这是一本应对软件系统越来越复杂的方法论的图书. 然而,在当时,中国的软件业才刚刚起步,软件系统还没有那么复杂,即使维护了几年,软件退化了,不好维护了,推倒重新开发就好了.

用DDD指导微服务拆分 - ThoughtWorks洞见

- -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.

深度解析DDD中台和微服务设计

- - DockOne.io
随着业务发展,领域模型和微服务会不断变化和演进,如何用最小代价来适应因为业务变化,而带来的领域模型和微服务演进. 建立 DDD、中台和微服务的统一语言. 我们先简单回顾一下中台的发展历程,2017 年《企业 IT 架构转型之道:阿里巴巴中台战略思想和架构实战》出版后,中台就受到业界热捧. 中台的出现是为了解决以往烟囱式和单体架构的重复开发、数据分散和试错成本高的问题,也是为了提高企业市场响应能力,解决巨型企业由于产品种类繁多、部门林立和沟通困难,而导致的商业模式创新难的问题.

Axon Saga的使用 | event sourcing | CQRS | axon | DDD | EdisonXu的技术分享

- -
在上一篇里面,我们正式的使用了CQRS模式完成了AXON的第一个真正的例子,但是细心的朋友会发现一个问题,创建订单时并没有检查商品库存. 库存是否足够直接回导致订单状态的成功与否,在并发时可能还会出现超卖. 当库存不足时还需要回滚订单,所以这里出现了复杂的跨Aggregate事务问题. Saga就是为解决这里复杂流程而生的.

DDD术语-聚合(Aggregate)、聚合根(AggregateRoot) - Louis军 - 博客园

- -
在事件风暴中,我们会根据一些业务操作和行为找出实体(Entity)或值对象(ValueObject),进而将业务关联紧密的实体和值对象进行组合,构成聚合,再根据业务语义将多个聚合划定到同一个限界上下文(Bounded Context)中,并在限界上下文内完成领域建模. 那你知道为什么要在限界上下文和实体之间增加聚合和聚合根这两个概念吗.

DDD CQRS 架构和传统架构的优缺点比较 - .net技术精选 - 开发者头条

- -
最近几年,在DDD的领域,我们经常会看到CQRS架构的概念. 我个人也写了一个ENode框架,专门用来实现这个架构. CQRS架构本身的思想其实非常简单,就是读写分离. 就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离.

Google开源LevelDB

- 酿泉 - Solidot
Google宣布在BSD许可证下开源其键值存储引擎LevelDB. LevelDB C++库可用于多种不同环境,如被浏览器用于存储最近访问的网页缓存,或者被操作系统使用去储存安装的软件包和依赖包清单,或被应用程序用于存储用户设置. Google称,即将发布的新版Chrome浏览器,就包含了基于LevelDB的IndexedDB HTML5 API实现.