基于 DDD 设计并实现模块化单体应用

阅读数:1549 2019 年 10 月 17 日 08:00

基于DDD设计并实现模块化单体应用

一个最近由 Kamil Grzybek 在 Github 发布的项目,给出了使用领域驱动设计(DDD,Domain-Driven Design)方法设计并实现一个单体(monolith)应用的详细介绍。该项目的目标,就是展示如何以模块化方式设计并实现一个单体应用。此外,Grzybek 还基于他在应用开发实践的收获,给出了一些有用的架构建议和设计模式。

Grzybek 是华沙 ITSG Global 的一位系统架构师,并担任团队负责人。他指出,该项目的目标并非是要创建一个极简应用,或是一个验证原型(PoC,proof of concept),而是给出一种适用于生产环境的完整实现。该项目的动机,来自于 Grzybek 对一些类似的但并未取得成功的项目的审视。在他看来,大多数示例应用过于简单,或是不够完整。他一直认为,这些应用至少在某些部分上存在着设计和实现上的问题,或是存在着相关文档缺失的问题。

Grzybek 强调指出,他的实现只是解决类似业务问题的许多方法之一。系统的软件架构需考虑多种因素,例如功能要求、质量属性和技术约束等,另一方面也会受开发人员的经验、技术约束、时间和预算等因素的影响,所有这些因素都会影响解决方案。

该应用针对的是为大多数开发人员所认可的会议组(meeting group)领域。应用实现中考虑了额外的复杂性,因此相比基于 CRUD 的常规应用更具意义。Grzybek 将主领域进一步划分为四个子域,即会议、支付、管理,以及用户访问。

为给出领域所需的功能,Grzybek 采用了一种称为“事件风暴”( Event Storming )的方法。该方法由 Alberto Brandolini 建立,用于探索复杂业务领域。Grzybek 使用该方法在主领域的各子域中发现行为和事件。

从更高层次上看,该架构中定义了一个 API 层、包含存储的四个模块(分别对应于所发现的四个子域),以及一个用于通信的公共事件总线(EventBus),如下图所示。

基于DDD设计并实现模块化单体应用

模块也相应地划分为四个子模块,并分别实现为独立的二进制文件,分别为:处理所有请求的 Application、实现领域逻辑的 Domain、实现基础架构代码的 Infrastructure,以及在 EventBus 上发布事件并且是模块间唯一共享组件的 IntegrationEvents。Grzybek 使用了 Decorator 模式,实现添加工作单元( Unit of Work )和日志等交叉关注点(cross-cutting)。

为分离应用内部的命令和查询,Grzybek 使用并实现了 CQRS 的一种变体。该 CQRS 变体针对命令所涉及的同一数据库表,在查询中使用了原始 SQL 和视图。虽然 CQRS 还具体其他变体,但 Grzybek 力图避免使应用过于复杂化。

模块间的集成是基于异步事件传输的。事件传输使用了“发件箱模式”/“收件箱模式”( outbox and inbox pattern ),以及基于内存中的 EventBus 代理。为存储要发布的事件,发件箱模式在数据存储中添加了独立的表。事件的添加,实现中通过执行任务的命令,以及等同于命令的事务。此后,这些事件通过单独的流程,转发到另一个模块的收件箱中。在该项目中,事件传输是通过各模块中的后台 Worker 实现的。该实现提供了多次交付和处理。

最后,Grzybek 强调该项目仍在开发中,欢迎贡献者的加入。项目是使用 C#编写的.NET Core 应用,使用了像 Autofac (用于 IoC )、 Dapper  (一种用于读取模型的 MicroORM )之类的类库。项目中还包括基于 Arrang-Act-Assert 模式的测试,使用 NUnit 实现。

在与 InfoQ 的访谈中,Grzybek 进一步详细介绍了他的设计理念。

InfoQ:相比基于微服务的设计,您如何评价单体应用的模块化设计?

Kamil Grzybek:与微服务体系架构相比,模块化单体应用的主要差别之处在于部署方法和模块间通信。

在微服务架构中,每个模块都以独立的进程运行。模块间的通信必须使用网络实现,并且通常通过同步服务 API 调用(即 RPC,远程过程调用),或是使用代理(即消息传递)实现。微服务架构是一种分布式系统,具有分布式的所有优点和缺点。
对于模块化单体应用,则无需考虑分布式系统。所有模块均以同一进程运行,无需使用网络即可相互通信。各模块可以通过方法调用直接同步引用内存中对象,或是异步地使用运行于同一进程中的某个中介者(Mediator)。

InfoQ:相比其他解决方案,例如一些消息传递平台,使用 EventBus 和发件箱 / 收件箱模式具有哪些优缺点?

Grzybek:模块化单体应用的主要优点,是开发人员无需使用任何消息平台,因为大多数功能都可以使用现有的设计模式在内存中实现。模块化单体应用本身可担当此类平台。当然,对于更高级的系统,使用独立的平台可能是更好的解决方案。但做出此决定时,必须谨慎。

InfoQ:您在 CQRS 模式的实现中,使用了视图和原始 SQL,而非单独的表。对此您能详细介绍一下吗?

Grzybek:我的方法虽然是一种最简单的 CQRS 实现,但其功能强大,通常完全够用。使用视图是应用和数据库之间的一种抽象和契约形式。开发人员可随时进入 CQRS 实现的下一层,读取应用逻辑可以保持不变。

下一层是物化视图。物化视图加快了读取的速度,但会导致写入性能略有下降。一些最先进的系统对于扩展性要求极高,它们引入了 CQRS 模式的最高层实现,并异步更新读取模型。这就是“最终一致性”。
每个实现层,都会增加解决方案的复杂性,因此,只有在真正需要时,我们才应去动更高的层。

原文链接:

Design and Implementation of a DDD-Based Modular Monolith

评论

发布