📕我是廖志伟,一名Java开发工程师、《Java项目实战——深入理解大型互联网企业通用技术》(基础篇)、(进阶篇)、(架构篇)清华大学出版社签约作家、Java领域优质创作者、优快云博客专家、阿里云专家博主、51CTO专家博主、产品软文专业写手、技术文章评审老师、技术类问卷调查设计师、幕后大佬社区创始人、开源项目贡献者。
📘拥有多年一线研发和团队管理经验,研究过主流框架的底层源码(Spring、SpringBoot、SpringMVC、SpringCloud、Mybatis、Dubbo、Zookeeper),消息中间件底层架构原理(RabbitMQ、RocketMQ、Kafka)、Redis缓存、MySQL关系型数据库、 ElasticSearch全文搜索、MongoDB非关系型数据库、Apache ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。不定期分享高并发、高可用、高性能、微服务、分布式、海量数据、性能调优、云原生、项目管理、产品思维、技术选型、架构设计、求职面试、副业思维、个人成长等内容。
🌾阅读前,快速浏览目录和章节概览可帮助了解文章结构、内容和作者的重点。了解自己希望从中获得什么样的知识或经验是非常重要的。建议在阅读时做笔记、思考问题、自我提问,以加深理解和吸收知识。阅读结束后,反思和总结所学内容,并尝试应用到现实中,有助于深化理解和应用知识。与朋友或同事分享所读内容,讨论细节并获得反馈,也有助于加深对知识的理解和吸收。💡在这个美好的时刻,笔者不再啰嗦废话,现在毫不拖延地进入文章所要讨论的主题。接下来,我将为大家呈现正文内容。
一、战略设计层
领域驱动设计(Domain-Driven Design,DDD)的战略设计层是整个设计框架的基石,它不仅涉及到如何将业务领域划分为不同的部分,还包括如何通过抽象和建模来定义这些部分的边界和交互,以及如何确保各个部分之间的协作和一致性。
-
领域划分 领域划分是DDD的核心概念之一,其目的是将复杂的业务逻辑分解为更易于管理和理解的多个领域,从而提升系统的可维护性和可扩展性。
- 核心域(Core Domain):包含业务的核心概念和规则,如订单管理、用户管理等。在实现上,核心域通常使用领域服务(Domain Services)来封装复杂的业务逻辑,并使用领域模型(Domain Model)来表示业务对象和关系。
- 支撑域(Supporting Domain):提供核心域所需的支持性服务,如用户管理、权限管理等。在实现上,支撑域可以采用标准的框架和组件,如Spring Security用于权限管理,Spring Data JPA用于用户管理。
- 通用域(Common Domain):提供跨多个领域的通用功能,如日期处理、日志管理等。在实现上,通用域通常采用独立的库或服务,如Java 8的DateTime API用于日期处理,Apache Commons Logging用于日志管理。
-
子域拆分原则 子域拆分是领域划分的细化,其目的是将一个领域进一步拆分为更小的、更具体的子域,以便于管理和维护。
- 按业务逻辑拆分:根据业务流程和业务规则进行拆分。例如,订单管理领域可以拆分为订单创建子域、订单修改子域、订单查询子域等。
- 按责任拆分:根据不同的业务职责进行拆分。例如,用户管理领域可以拆分为用户注册子域、用户登录子域、用户信息修改子域等。
- 按技术实现拆分:根据技术实现难度和依赖关系进行拆分。例如,将数据访问层(Data Access Layer,DAL)作为独立的子域,以便于技术栈的更换和升级。
-
限界上下文边界定义 限界上下文是DDD中用来定义领域边界的概念,它明确了哪些对象和规则属于同一个上下文。
- 闭合边界:限界上下文内部的对象和规则不对外界可见。在实现上,可以通过封装和抽象来保护领域模型,确保其内部的一致性和稳定性。
- 开放边界:限界上下文通过接口与其他上下文交互。在实现上,可以使用适配器(Adapter)或中介者(Mediator)模式来封装不同上下文之间的交互,降低耦合度。
-
统一语言 统一语言是DDD中用来确保团队成员对领域模型有共同理解的方法。
-
术语表构建方法:
- 收集领域专家的术语:通过访谈、研讨会等方式,收集领域专家对业务领域的描述和术语。
- 定义术语的精确含义:对收集到的术语进行定义和解释,确保团队成员对术语的理解一致。
- 确保术语的一致性:在文档、代码和沟通中使用统一的术语,避免产生歧义。
-
跨团队语义对齐:
- 定期组织沟通会议:通过团队会议、代码审查等方式,确保团队成员对领域模型的理解一致。
- 使用统一的文档和模型:使用UML、ER图等工具,将领域模型文档化,方便团队成员查阅和交流。
- 进行代码审查和设计评审:通过代码审查和设计评审,确保团队成员按照统一语言进行开发。
-
上下文映射模式:
- 合作关系:定义不同上下文之间的协作方式,如事件发布/订阅模式、服务调用等。
- 客户-供应商:定义上下文之间的依赖关系,如限界上下文作为客户,基础设施作为供应商。
-
二、战术设计层
战术设计层是DDD的具体实现层,它涉及到如何将战略设计层定义的领域模型转化为可执行的代码。
-
基础构件 基础构件是构建领域模型的基本单元。
-
实体标识设计:
- UUID:使用UUID作为实体的全局唯一标识符,确保实体的唯一性和不可变性。
- 数据库序列:使用数据库自增序列作为实体标识,提高数据访问效率。
-
值对象不可变性实现:
- 值对象:使用不可变对象来表示数据,避免数据被意外修改。
- 不可变性:一旦创建,值对象的状态不可改变,提高系统的稳定性和可预测性。
-
-
服务架构 服务架构定义了领域服务的组织方式和与应用服务的关系。
-
领域服务与应用服务区分:
- 领域服务:处理复杂的业务逻辑,如订单创建、用户管理等。
- 应用服务:处理与外部系统的交互,如发送邮件、处理支付等。
-
工厂模式应用场景:
- 创建复杂对象:使用工厂模式创建复杂对象,降低代码复杂度。
- 需要重用对象创建逻辑:使用工厂模式封装对象创建逻辑,提高代码复用性。
-
仓储接口设计(CQRS模式):
- CQRS(Command Query Responsibility Segregation):将读操作和写操作分离,提高系统性能和可扩展性。
-
-
事件驱动 事件驱动是一种设计模式,它通过事件来驱动业务流程。
-
领域事件建模:
- 事件:业务发生的重要事情,如订单创建、用户登录等。
- 事件源:触发事件的实体,如订单服务、用户服务等。
-
事件溯源实现:
- 事件溯源:通过事件记录来恢复系统的状态,提高系统的可恢复性和可扩展性。
-
最终一致性策略:
- 最终一致性:系统状态最终达到一致,但不保证立即一致。在实现上,可以使用消息队列、分布式锁等技术来保证最终一致性。
-
三、规则体系
规则体系是DDD中用来定义和执行业务规则的部分。
-
业务规则 业务规则是业务逻辑的具体体现。
-
前置条件验证:
- 验证业务操作的前提条件是否满足,如用户权限、订单状态等。
-
不变式约束:
- 定义实体的不变性质,确保实体状态的正确性,如订单金额、用户年龄等。
-
规则引擎集成:
- 使用规则引擎来执行业务规则,提高系统的灵活性和可扩展性。
-
-
流程规则 流程规则定义了业务流程的控制逻辑。
-
状态机设计:
- 状态机:描述实体在不同状态之间的转换,如订单状态的变化。
-
工作流引擎对接:
- 使用工作流引擎来管理业务流程,提高流程的自动化和可管理性。
-
Saga事务补偿:
- Saga:通过一系列本地事务来协调分布式事务,提高系统的可靠性和可扩展性。
-
四、扩展实践
扩展实践是DDD在实际项目中应用的延伸,它提供了多种方法和工具来提高DDD的实用性和可维护性。
-
架构集成 架构集成是将DDD与其他架构模式和技术集成的方法。
-
六边形架构适配:
- 六边形架构:将系统分为内、外两个环,内环是领域,外环是基础设施。
-
事件风暴工作坊:
- 事件风暴:通过团队讨论来定义领域事件和事件处理。
-
微服务拆分模式:
- 微服务:将系统拆分为多个独立的服务,提高系统的可扩展性和可维护性。
-
-
效能工具 效能工具是提高开发效率的工具。
-
代码生成框架:
- 自动生成代码,减少重复劳动。
-
契约测试工具:
- 自动化测试接口和业务逻辑。
-
可视化建模平台:
- 使用可视化工具来设计和展示领域模型。
-
📥博主的人生感悟和目标
- 💂 博客主页: Java程序员廖志伟希望各位读者大大多多支持用心写文章的博主,现在时代变了,信息爆炸,酒香也怕巷子深,博主真的需要大家的帮助才能在这片海洋中继续发光发热,所以,赶紧动动你的小手,点波关注❤️,点波赞👍,点波收藏⭐,甚至点波评论✍️,都是对博主最好的支持和鼓励!
- 👉 开源项目: Java程序员廖志伟
- 🌥 哔哩哔哩: Java程序员廖志伟
- 🎏 个人社区: Java程序员廖志伟
- 🔖 个人微信号:
SeniorRD
📙经过多年在优快云创作上千篇文章的经验积累,我已经拥有了不错的写作技巧。同时,我还与清华大学出版社签下了四本书籍的合约,并将陆续出版。这些书籍包括了基础篇、进阶篇、架构篇的📌《Java项目实战—深入理解大型互联网企业通用技术》📌,以及📚《解密程序员的思维密码--沟通、演讲、思考的实践》📚。具体出版计划会根据实际情况进行调整,希望各位读者朋友能够多多支持!
🔔如果您需要转载或者搬运这篇文章的话,非常欢迎您私信我哦~
8425

被折叠的 条评论
为什么被折叠?



