记录 DDD中服务间调用的写法

问：直接在领域层调用UserRpc（外部服务）会限制基础设施层的技术选型这个是什么意思

这句话的意思是，如果在领域层直接调用UserRpc这种与特定技术实现紧密相关的组件，那么当需要对基础设施层的技术进行调整或更换时，就会受到很大的限制。

例如：

假设目前UserRpc是通过某种特定的 RPC 框架实现的，用于从外部获取用户信息。如果领域层直接调用了UserRpc，那么如果后续想要更换 RPC 框架，或者改为使用 RESTful API、消息队列等其他技术来获取用户信息时，就需要在领域层的代码中进行大量的修改。

因为领域层的业务逻辑已经与特定的UserRpc及其所使用的技术实现紧密耦合在一起了。这就使得基础设施层的技术选型变得非常不灵活，无法根据实际需求和技术发展进行自由调整和优化，从而影响整个系统的可扩展性和可维护性。

意思就是，把userRpc的技术改了，可能要同一个东西，调用方式不同了，比如，这个userRpc用的是openFeign来的，要是改成其他的Rpc框架，可能就不一样了，所有要写到应用层，减少对邻域层业务的耦合，对核心业务的影响。

问：就是在这一层再加一个service包用来放这些的调用是吗

这一层添加一个 service 包来放置对外部服务的调用逻辑以及协调领域层和基础设施层的业务逻辑处理。

这样做有以下几个好处：

一、结构清晰

1. 将不同类型的代码进行分类放置，使得整个应用层的结构更加清晰。controller 包主要负责接收请求和返回响应，而 service 包专注于业务逻辑的处理和外部服务的调用，职责更加明确。
   • 例如，在开发和维护过程中，开发人员可以更容易地找到特定功能的代码所在位置，提高开发效率。
2. 对于复杂的业务场景，可能需要多个外部服务的调用和协调处理。将这些逻辑放在 service 包中，可以避免 controller 层变得臃肿和复杂。
   • 比如，一个业务流程可能需要调用用户服务、订单服务和库存服务等多个外部服务，在 service 包中可以更好地组织和管理这些调用逻辑。

二、可维护性和可扩展性

1. 如果需要对外部服务的调用逻辑进行修改或扩展，只需要在 service 包中进行相应的修改，不会影响到 controller 层和其他部分的代码。
   • 例如，如果外部服务的接口发生变化，只需要在 service 包中更新调用逻辑，而 controller 层可以保持不变，降低了维护成本。
2. 当需要添加新的业务逻辑或调用其他外部服务时，可以在 service 包中进行扩展，不会对现有代码结构造成太大的影响。
   • 比如，随着业务的发展，需要添加一个新的功能模块，涉及到调用新的外部服务，可以在 service 包中创建新的服务类来处理这个功能，而不会影响到其他已有的功能模块。

三、符合设计原则

1. 遵循了分层架构的设计原则，将不同层次的职责进行分离。controller 层负责与用户交互，service 层负责业务逻辑处理和外部服务调用，领域层负责核心业务规则的实现，基础设施层负责技术实现。
   • 这样可以提高系统的可维护性、可扩展性和可测试性。
2. 使得代码更加符合单一职责原则，每个包中的代码只负责特定的功能，降低了代码的耦合度。
   • 例如，service 包中的服务类只专注于业务逻辑和外部服务调用，不会涉及到请求处理和响应返回的逻辑。

最后自己总结：

ddd架构，

用户界面层：负责与用户进行交互，接收用户的输入并将系统的响应展示给用户。这一层通常包括 Web 界面、移动应用界面等

应用层：协调多个领域服务的执行，处理业务用例。应用层还负责处理事务、安全等横切关注点。

领域层：把核心业务写在邻域层，业务领域的核心概念、规则和逻辑。

基础设施层主要是对其他层次提供技术支持，如数据库访问、消息队列、缓存等。基础设施层中的代码通常是通用的技术实现，不包含任何业务逻辑。

最后还需了解：

领域层好像还有个聚合根