30｜限界上下文（下）：限界上下文之间如何集成？

问题一：假设两个限界上下文是由两个团队负责的微服务，当两个限界上下文只有少量相同的逻辑，最好就各自维护自己的，用少量的重复来换取两个团队之间的沟通成本，当两个限界上下文出现了很多的重复逻辑那就可以考虑把相同的逻辑抽取成一个单独的微服务，并提供给之前的那两个微服务去调用。 问题二：仓库作为防腐层屏蔽了实体的获取细节，其实Controller也是防腐层，它屏蔽了不同的请求协议。

对于从单体应用--->微服务应用的设计图有一点疑问, 在单体应用中EffrotItemService会直接调用EmpRepository来获取Emp. 但是在微服务应用的设计里EffrotItemService只依赖了EMP .没有看到如何通过EmpRepository来获取Emp . 请问在微服务应用的设计中EffrotItemService是如何通过EmpRepository获取EMP的

防腐层我一直没搞明白，一般放在哪个调用模块中还是被调用模块中呢？有没有示例代码，可供参考学习学习？

几个限界上下文在同一个微服务中，互相间的调用都通过反腐层调用的方式，会多出不少的转化的代码，特别是dto转domain对象，这个代价相对于收益是否划算？我们是否也可以两个领域对象Emp间进行转化呢？要拆分微服务的时候再去做防腐层调用及dto转domain对象

来自新必应对思考题的回答： 问题一 这是一个很好的问题。限界上下文是用来细分领域，从而定义通用语言所在的边界1。限界上下文之间可能存在依赖或重叠，这时候就需要考虑是否抽取成可重用的模块。 根据我的搜索结果，有以下几种可能的做法： 如果两个限界上下文之间有类似或相同的部分，但是它们的含义和行为不一样，那么就不应该抽取成可重用的模块，而是应该保持各自独立。 如果两个限界上下文之间有类似或相同的部分，并且它们的含义和行为一致，那么可以抽取成可重用的模块，并且在物理层面上进行无缝集成3。这种情况下，需要注意避免开发人员绕过防腐层直接调用另一个限界上下文的代码。 如果两个限界上下文之间有类似或相同的部分，并且它们的含义和行为基本一致，但是有些细节不同，那么可以抽取成可重用的模块，并且在逻辑层面上进行隔离3。这种情况下，需要使用防腐层进行模型或协议的转换。 问题二 防腐层是一种用于隔离两个系统的模式，可以在不知道对方领域知识的情况下进行集成¹。防腐层主要进行的是两个系统之间的模型或协议的转换。 除了在仓库里以外，防腐层还可以作为应用程序内的组件或作为独立服务实现。但是，防腐层也有一些问题和注意事项，比如可能增加调用延迟、管理和维护成本、缩放方式等。 我的读后感 1. 好强大的设计：不论采用哪种策略，概念层面的映射关系都是一样的，只是实现层面不同 2. 又学到了一个根据不同实现技术分层的原则：访问数据库用 persistence、访问别的 service 用 gateway 或 proxy

是否重用跟技术难度和组织也有很大关系，难度不大谁都能写直接就写了；组织中如果专门有人负责公共组件并且有制度约束那重用概率就大。 限界上下文划分微服务要看粒度，很多时候作为一个小模块，子功能就可以，不需要拆分微服务，不能为了拆而拆，不同上下文的概念映射，数据同步带来了复杂性，要权衡是否必要。

作为AI语言模型，我认为抽取成可重用的模块是有必要的。这样可以避免重复的代码，提高代码的可维护性和可重用性。而且如果有多个限界上下文中需要使用相同的部分，抽取成模块可以方便地在各个上下文中进行使用和维护，同时还能降低代码的耦合性，提高系统的灵活性和可扩展性。

思考题： 1. 在实际开发过程中，遇到上下文的实体重复，我们会把 xxRequest、xxResponse 放在一个 common 包里，多个服务用一个 common jar 包 2. 有时候能否也在应用层去实现，应用层一边调用领域层，然后再调用其他上下文，转换逻辑放在调用层里的上下文映射实体里