DDD 中关于应用架构的那些事( 三 ) _架构

• PL(Published Language)：发布语言，通常跟 OHS 一起使用，用于定义开放主机的协议。
• ACL(Anticorruption Layer)：防腐层，一个上下文通过一些适配和转换，来跟另一上下文交互。
我们平时大多数时候的开发工作，都是跟 Grpc/Kitex 等 RPC 框架打交道的，不同的框架在设计之初都会定义一份协议，只有符合协议要求的请求才能被正确地识别和处理。比如 Grpc 使用 HTTP2 作为传输协议，而 Kitex 则主要使用自定义的 TTHeader 协议。
这些框架在使用上，一个共同特点就是需要通过 IDL(Interface description language) 来定义服务可以提供的能力。IDL 中可以定义多个接口，每个接口都有一个方法名，同时需要指定传递什么参数，返回什么数据。这样的一份 IDL 就可以认为是我们为系统定义的发布语言。
还是以前面多次提到的商品服务为例，商品服务作为上下文集成中的被集成方，通过 thrift 定义了其可以提供的服务，比如下面是对 GetProductDetail 接口的定义：

文章插图
所以，如果我们是一个服务的提供方，只要我们使用 Grpc/Kitex，那么就可以认为我们是使用 OSH 和 PL 方式来进行集成的。
?? 防腐层
防腐层一般用在下游上下文中，可以用来隔绝上游上下文中可能发生的变化。
在上面的例子中，商品服务提供了一个 GetProductDetail 接口，用以返回关于 Product 的全量信息。但是对于其他集成方来说，可能只是想拿到产品的很少一部分信息，比如在订单服务中要展示订单的详情，而详情只需要产品的图片和名称即可。
可以看到，作为服务的提供方，其具有追求普适性和灵活性的特点，而服务的调用方，在使用时却想要能够集中满足特定需求的接口。
这种张力是导致在边界上出现问题的主要原因，是无法避免的，但是却是可以解决的，应对的方法就是使用防腐层。

文章插图
从图中可以看出，Subsystem A 和 Subsystem B 的调用关系并不是直接产生的，都要通过中间的一个ACL，ACL 除了负责执行具体的技术性调用，还将 A 和 B 的领域模型隔离开来，并承担了彼此模型之间的翻译转换功能。
除此以外，还可以在 ACL 做缓存、兜底、开关等功能。
对于集成方来说，一般采用独立接口的形式，接口的定义放在 interfaces 中，上面这个例子就可以这样定义：

文章插图
因为实现是跟具体的技术相关的，所以实现需要放到基础设施层。整体的目录层级如下：

文章插图
具体的实现可以参考下面的代码，简单来说就是将通过 RPC 获取到的上游模型，转换为自己领域内的模型：

文章插图
在传统意义的防腐层实现中，会有一个适配器和一个对应的翻译器，其中适配器的作用是适配对其他上下文的调用，而翻译器就是将调用的结果转换成本地上下文中的元素。
在这里，我们为了保持代码的简单，没有特意声明这样两个对象，rpc的方法在这里起到了适配器的作用，至于翻译器，我们只是简单的提出了一个方法，在方法名上做了特殊的前缀修饰。
最后，ProductRpcClient 会作为 ProductClient 的实现类，最终被注入到服务中。
03? CQRS 简单实现
我们在看一些资料时，可能会看到有的地方叫CQS有的又叫CQRS 。CQS 和 CQRS 都表示命令与查询的分离，本质上没有太大的区别。
CQS 是在《面向对象软件架构》一书中提出来的概念，作者 Bertrand Meyer 认为，一个方法原则上不应该既修改数据又返回数据，所以就有了两类方法：
1、查询：返回数据，但不修改数据，不会产生副作用；
2、命令：修改数据，但不返回数据，存在副作用。
CQRS 是对 CQS 概念的升华，因为查询端只返回数据，完全不修改数据，所以我们所有的查询不需要走领域实体，甚至没必要使用 ORM 框架，总之，我们可以通过各种手段来提升查询的效率。
关于CQS与CQRS的更多信息，可以参考这篇文章，和这篇。
下图是在各种技术文章中你会经常看到的一个非常典型的 CQRS 架构示例：