DDD(Domain-Drive Design)由Eric Evans(埃里克·埃文斯)提出，为解决复杂性而诞生，是综合软件系统分析与设计的面向对象建模方法；将需求分析与模型设计统一同时实现以业务实体为核心的灵活扩展；通过分层的方式将领域划分在不同的层次实现业务逻辑的剥离，从而控制业务本身的复杂度；
1. DDD要点
-
数据库为中心与业务领域为中心模型对比：
db-ddd.png
1. DDD定义了领域模型
- DDD架构打破了系统分析(需求分析)和系统设计的隔阂，提出了领域模型的概念从而统一了分析与设计，使得软件能够更灵活的跟上需求的变化。
- 领域在 DDD 中占据了核心的地位，DDD 通过领域对象之间的交互实现业务逻辑与流程，并通过分层的方式将业务逻辑剥离出来，单独进行维护，从而控制业务本身的复杂度。
- DDD需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。
- DDD让首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同；
1.2 领域模型与SOA微服务
- DDD+SOA微服务器的事件驱动架构实现CQRS的读写分离，应对复杂业务逻辑。
- DDD的聚合模型+事件驱动代替SOA的数据表模型+消息驱动。
- 领域模型的价值在于提供一种通用的语言，使得领域专家、产品经理和软件技术人员联系在一起，沟通无歧义；
2. DDD落地架构
DDD 作为一种系统分析的方法论，最大的问题是如何在项目中实践。而在实践过程中必然会面临许多的问题，「模式」是系统架构领域中一种常见的手段，能够帮助开发人员与架构师在遭遇某种较为棘手，或是陌生的问题时，参考已有的成熟经验与解决方案，从而优雅的解决自己项目中的问题。
2.1 CQRS模式
- CQRS全称为Command Query Responsibility Segregation，中文名为命令查询职责分离，故名思义是将command与query分离的一种模式。
- 命令是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。
- 而查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。
- CQRS 的核心思想是将这两类不同的操作进行分离，然后在两个独立的服务中实现。这里的服务一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上。
-
CQRS架构图：
CQRS架构图
- CQRS带来的问题1：不支持事务引起的数据不一致问题；
- CQRS带来的问题2：实时性差引起的事件延迟问题；
- CQRS带来的问题3：没有成熟的框架(包括Axon框架)，一般需要手动实现；
2.2 其它模式
- Clean架构
- 六边形架构
- Event Source
其它名词
- CRUD
- 失血模型与充血模型
- 领域模型
- 聚合模型
- 领域事件与消息中间件
网友评论