领域驱动设计(以下简称DDD)是一种软件设计的方法思想, 是面向对象的进阶, 他可以指导软件系统(不论是单体应用还是微服务都可以)的设计和开发.
DDD使研发者的目光聚焦在业务本身, 使技术架构和代码实现成为领域建模的副产品. 程序员都是技术性思考者, 总是擅长从技术的角度来解决项目问题, 但一个软件的可用性是通过它所提供的业务价值 来实现的, DDD正是这个问题的一种行之有效的解决方法.
# 常见的实现业务的两种方式
- service + 贫血模型的实现
传统的service + 贫血模型主要特点是存在一个贫血的领域, 业务逻辑通过一个service类去实现, 这是一中面向过程的编程范式, 其中的领域对象只是充当了数据库记录的容器, 在项目持续演进的过程中, 这些业务逻辑会分散在不同的Service类中，最终的结果是代码变得越来越难以理解进而逐渐丧失扩展能力.当然, 这种模式也有一些好处:
- 简单直观, 程序员在学习完编程基础之后和数据库的CRUD操作之后就可以开发;
- 效率高, 短时间内完成应用的开发;
- 模块之间非常独立.
- 基于事务脚本的实现
在上一种实现方式中, 领域对象的存在的目地即让ORM框架进行一次性持久化, 在抛弃ORM的情况下, 领域层已经没有了存在的必要, 业务逻辑直接嵌入到了SQL中.
但是当业务复杂之后, 这种模式的就会带来一些问题.
虽然都是对数据库进行修改, 但是中间存在的大量的业务逻辑没有得到良好的封装, 如果某个新手程序员擅自修改了某个数据片段, 整体业务就将被破坏, 这是因为没有一个真正的领域对象去负责执行相关的业务 逻辑, 一个service中的方法直接就对数据库完成了修改, 要保持对业务逻辑的完整性, 完全凭借程序员对系统的了解.
# 领域驱动的实现业务方式
它将以面向对象的思考方式, 将领域对象当做是服务的提供方, 而不是数据容器, 更多的思考一个领域对象能够提供哪些行为, 而不是数据.
在DDD中代码就是设计本身. 不再需要那些繁文缛节的并且永远无法得到实时更新的设计文档, 程序员与领域专家也不再需要翻译才能理解对方所表达的意思. DDD战略设计和战术设计之分. 战略设计从高层俯视软件系统, 帮助精准划分领域与处理各个领域之间的关系; 战术设计从技术层面指导如何具体实施DDD:
ps: 只有DDD的软件才是好软件, 推荐站点 (opens new window)