DDD-领域驱动设计

Domain Driver Design

17年时候接触过DDD，纪念过去了，基于自己的经验简要说明一下

一个项目从0-1的过程。首先大家收集需求，然后开个会进行头脑风暴，主要技术和主要产品负责大体规划，规划好业务模型，技术模型。我任务技术和业务是互补并且相互借鉴的。

要想定好业务模型需要从下面几个方面考虑

上下层模型：细化上下文，比如用户是基础，属于底层，在往上找就是i积分，卡券，在往山找就是订单，和订单平级的又会有活动营销。

降低耦合度：不要让模型相互耦合，尽量做到相互独立

抽象、分治、方法：将业务抽象出来，分门别类，提出问题，给出解决方法来解释抽象出来的业务的和理想

比如我们公司：老板确认了目标，有了一个大致的分析结果，大家多开几次会，自己会后思考总结，继续开发，确定党项目标，有了结果和目标之后 ， 产品出商业蓝图 BRD , 之后确定PRD、技术选型，技术架构：根据业务架构确定系统架构，确认技术架构

业务架构：市场需求调研，设计出合理的业务模块

系统架构：设计系统上下层模块，确认子系统。

技术架构：技术选型、技术框架

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

但我觉得业务架构和系统架构是相辅相成的。之前有一个产品就是基于技术出的系统架构，才确定业务架构

设计领域模型的一般步骤如下：

1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

当然我们再平时开发子系统，子业务也会有DDD的影子在

举个例子 xxl-job 

https://blog.csdn.net/weixin_41596285/article/details/129828685

 

自问自答

1、DDD是解决什么问题？

领域驱动设计是为了帮我们解决复杂业务的分析、架构、代码落地问题，当然我们不能一味的遵循，对于一些简单的场景，通常省略领域层未尝不可。

毕竟DDD是为了帮我们解决问题，而不是强制使用某种规范来限制我们。

2、是否有一套通用的DDD落地方案或框架？

我们需要结合实际场景来使用。

3、如何驱动领域设计流程？

首先要人人达成共识，对概念进行统一，对描述词汇进行沉淀和统一管理，有意识的在沟通中使用这些词汇来描述业务或者场景，以达到最终落地的效果

4、java架构上理解？

• PO (Persistent Object)：指持久化对象，用于表示数据库表中的一行记录。
• BO (Business Object)：指业务对象，是指封装了业务逻辑的 Java 对象，用于处理业务流程中的操作和计算。
• VO (View Object)：指视图对象，通常用于前端页面展示，封装了从服务端返回的数据。
• DTO (Data Transfer Object)：指数据传输对象，是用于在不同层之间传输数据的对象，通常用于服务端与客户端之间、服务端不同层之间的数据传输。
• Entity：指实体对象，用于表示系统中的一个实体，通常对应数据库中的一张表或者一个文档。