2019-04-19 | UNLOCK

领域驱动设计(DDD:Domain-Driven Design)

什么是领域驱动设计?

领域驱动设计(英语:Domain-driven design,缩写 DDD)是一种通过将实现连接到持续进化的模型[1]来满足复杂需求的软件开发方法。领域驱动设计的前提是:

  • 把项目的主要重点放在核心领域(core domain)和域逻辑
  • 把复杂的设计放在有界域(bounded context)的模型上
  • 发起一个创造性的合作之间的技术和域界专家以迭代地完善的概念模式,解决特定领域的问题

其实在软件开发中最大的和最常见的是这两个问题

  1. 技术难点
  2. 领域业务理解难题

因为开发在领域中不是很了解业务,让开发不断的在修改业务,修改逻辑,往往开发在开发中是按照以往,或者之前的一些”做过的业务”来去理解一些目前需要的一些业务,大部分都导致代码重构,业务重写等等加大开发成本,以及开发压力

Build Domain Model 建立领域知识

由设计者进行统一的领域建模,然后反复和的领域专家进行确认,这个模型是否是正确的领域模型

  • 失血模型:模型仅仅包含数据的定义和getter/setter方法,业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO,在.NET中叫POCO。
  • 贫血模型:贫血模型中包含了一些业务逻辑,但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出,贫血模型中的领域对象是不依赖于持久层的。
  • 充血模型:充血模型中包含了所有的业务逻辑,包括依赖于持久层的业务逻辑。所以,使用充血模型的领域层是依赖于持久层,简单表示就是UI层->服务层->领域层<->持久层
  • 胀血模型:胀血模型就是把和业务逻辑不想关的其他应用逻辑(如授权、事务等)都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型,因为服务层消失了,领域层干了服务层的事,到头来还是什么都没变。

总结

轻代码,重设计于测试

评论加载中