DDD（领域驱动设计）的这些问题，你都知道吗？

忘是亡心i 2023-10-18 23:15 181阅读 0赞

点击上方蓝字可以订阅哦

本文中的问题精选自上期【你问我答】——DDD（领域驱动设计）专题中读者的提问。【你问我答】是由美团点评技术团队推出的线上问答服务，你在工作学习中遇到的各种技术问题，都可以通过我们微信公众号发问，我们5000+工程师会义务为你解答，欢迎大家踊跃提问。高质量、定义清晰的问题会优先获得解答。

编者按

DDD就是帮助工程师快速理解和提炼业务本质或核心的一套方法。

DDD又分战略设计和战术设计，这两个混一块就没法谈了。战略设计就是画一个圈，把里面的模型建出来。战术设计就是，在物理层次想尽一切办法保证边界不被突破和内部模型的状态的一致性，具体怎么落地有各种各样的做法，这时考验的是工程设计能力。

另外，因为DDD属于一种思想，所以大家对同一个问题可能有不同的看法，这些看法虽然不同，却为我们解决问题提供了多样化的思路，所以我们这次将不同同学的回答都放置在问题下面，希望对大家有所帮助。

**Q1：****我使用事件、工作单元、观察者模式简单使用了下领域事件，接下来想做成事件与业务在同一数据库事务中写入表，然后异步执行。这一块你们有怎样的使用方案，遇到过什么问题需要注意些什么？**

> A1：系统设计上区分存储层和产品层，好的存储层/模型可以支撑若干差异产品流程和玩法。
> 
>   
> 
> 
> A2：这个问题没太理解，感觉这位同学说的已经是解决方案了，不是在说问题。试着回答下：一是要注意事件引擎是不是作为中间件建设的，如果是的话，这样做有一定的入侵性，但是能获得较好的事务保障；二是事件落地会带来一些数据库操作，会带来额外的数据库负载，根据你设计的事件粒度和事件处理状态粒度，这个开销会非常可观。

**Q2：****我在设计服务RPC接口时，遵循了一个规则，就是参数类只包含所需的字段，不多不少，也担心以后可能加不同的字段，所以为每个接口创建了单独的参数类，从而导致类泛滥等各种问题。后来想了办法，使用聚合方式拆分成小粒度的参数类，接口就多几个参数而已，就是可能会超过3个这点不好，但不像以前麻烦了，你们是怎么做的？其实聚合或领域服务都会有超过3个参数的情况，你们是否允许这样？ 服务接口实现我觉得就是应用层，MVC控制器是用户接口层，我的理解是否正确？另外接口需要先校验参数，比如非空枚举值校验，还是有必要的，但聚合和实体中也有这样的校验，感觉参数校验是泄露了领域逻辑，该怎么正确理解？**

> A1：根据六边形结构，领域层暴露领域层接口，应用层暴露应用层接口。如果是命令接口，必须由适配层转换为六边形内部定义的参数。如果是查询，根据CQRS理论，怎么方便怎么来。
> 
>   
> 
> 
> A2：如果使用事件，对应问题是事件的前置达成条件，是以存储层成功为准还是产品层成功为主。所以存储层和产品层之间的关系和定位需要先想好。

**Q3：DDD****中的自治和微服务的自治有区别没？**

> A1：DDD只做六边形内部的状态自治，和SOA的服务自治是正交的。
> 
>   
> 
> 
> A2：事务是另外一件事，是存储层/存储介质来关注的。我个人认为事件与事务没关系（我个人在实施上存储和产品是隔离的）。
> 
> 1. 服务自治：DDD和微服务的关注没区别。理论基本一致，DDD多了落地的指导。  
> 2. DDD多了一个业务自治，这个是最难的部分。
> 
>   
> 
> 
> A3：服务自治：自治分功能自治和质量自治，DDD主要是功能部分，也就是业务，微服务两者皆有。

**Q4：****做SOA时，如果一个服务内需要调其它服务接口，我考虑的办法是当前服务内创建对应的聚合实体仓库，仓库实现类里调用其它接口。这样做是否合适，你们有其它方法没？不过这样给人一种本地事务的感觉，如果有事务补偿，就有点别扭。**

> A1：我只在数据读取的时候这么做，涉及到数据更新千万别这么做……
> 
> A2：事务补偿如果做到框架里面，或者通用解决方案，就不会觉得别扭了。

**Q5：****看书上的例子觉得很有用，但是看自己遇到的业务场景又觉得没有用。拿创建订单来说，“创建”这个动作应该放到哪里比较好呢？**

> A1：创建订单就用订单工厂，这个和DDD没太大关系，就是设计模式的应用。
> 
>   
> 
> 
> A2：个人认为这个需要具体看。订单只是一个业务的概念，需要根据具体的业务需求，来定义订单这个词映射在领域语言中是什么。也许就是商家和用户之间的一种“合同”，亦或许只是个“日志”而已。

**Q6：****请推荐一些靠谱的资料，能够让我快速掌握DDD的大方向。**

> A1：《实现领域驱动》、Jdon网站关于DDD的讨论。
> 
>   
> 
> 
> A2：领域设计和服务化的区别，是对领域的理解、抽象、组合。 所以先看OOA、OOD、OOP会更有帮助。否则实施的结果，只是在做服务化。

**Q7：****请教，如何区分领域边界，是否可以分享一下经验。**

> A：限界上下文的提取貌似没有一个固定的办法，我习惯先收集领域词汇，在领域词汇里找到可能成为独立系统的叶子节点，然后在叶子节点中寻找内在联系，将叶子节点聚合在一起形成限界上下文，最后再站在客户角度和行为分析的角度修正一下。

**Q8：****如果对2个聚合的“读取并统一返回的”操作，这端逻辑是放在领域服务还是放在应用层比较合适？**

> A：个人理解是应用层，CQRS最初就是为了解决这种问题提出来的。

关于DDD，如果你有其它方面的疑问，可以扫下面的二维码，回复关键词“DDD”加入我们的微信群进行提问和讨论哦~赶快拿出手机扫一下吧~

![640?wx\_fmt=png][640_wx_fmt_png]