何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了。领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architecture Pattern),它也不是一种软件开发方法论,所以,是否应该使用领域驱动设计,以及什么时候使用领域驱动设计,这个问题本身就比较复杂(或者说这并 不是一个好问题)。或许,更精确的提问方式应该是:“我应该选择什么样的架构风格来构建我的系统?”。现在我们先不急着回答这个问题,还是回到领域驱动设计的话题上,来回顾一下领域驱动设计里的基本概念。
领域驱动设计
很多人都了解测试驱动开发(TDD)、功能驱动开发(FDD)、API驱动开发(ADD)和行为驱动开发(BDD),那么什么又是领域驱动设计(DDD)呢?DDD的第三个D为什么是“设计”而不是“开发”呢?领域驱动设计最开始提出来的目的是为了简化业务人员与开发团队之间的沟通,以保证开发出来的软件产品不仅能够很好地解决业务领域问题并满足客户的需求,而且还能够简化或解决传统软件开发过程中遇到的各种问题(比如需求变更、横向或纵向扩展性差等等)。因此,通用语言(ubiquitous language)就是领域驱动设计中最重要最核心的概念:它能够确保代码的组织方式能够直接反映业务模型和业务逻辑,并且在整个业务系统中,对于同一个业务概念使用相同的代码表述(比如银行系统中的Account对象)。从通用语言的定义出发,领域驱动设计对于业务领域建模提供了一些指引,具体表现为引入了实体(Entity)、值对象(Value Object)、服务(Service)、聚合(Aggregate)、聚合根(Aggregate Root)、工厂(Factory)和仓储(Repository)。这里我就不打算深入讨论这些概念了,就简单回顾一下吧。