洋葱架构、持久性和通知答案

【问题标题】：Onion Architectures, persistence and notifications洋葱架构、持久性和通知
【发布时间】：2023-03-17 04:23:02
【问题描述】：

我正在学习 洋葱架构，我有一个观点。

洋葱架构旨在将领域与技术工件隔离开来。因此，指导方针是让数据访问层 (DAL) 引用域层 (BL)。这样，我应该能够将实体转换为存储工件。引用 BL 可能会给我我的域的“快照”，但如果没有更改跟踪系统，我将丢失所有按时间顺序排列的事件，以了解是否插入、更新或删除数据存储中的项目，以便能够正确地补充水分之后的模型。

洋葱架构是否总是需要一些更改跟踪系统，或者甚至像事件存储这样的东西？我是否缺少任何其他模式？

【问题讨论】：

事件存储只是一种持久化机制。洋葱架构定义了外部依赖的顺序，但没有说明你应该使用什么持久性。这些是您的实施细节。

标签： c# design-patterns architecture domain-driven-design onion-architecture

【解决方案1】：

领域层是否知道何时需要持久化？

例如，我可能有一个新/更新客户屏幕，当我按下完成时会保存一个新客户。那时我不关心更改跟踪，我只想存储我拥有的所有内容。我的 DAL 可以确定我是否在数据库中已经有一个同名的客户（如果它应该发出插入或更新查询）。

同样的事情也适用于事件存储。如果您的域关心事件、能够撤消事件等，则如果是技术实现，则事件存储，

可能发生的情况是，您的领域层总是由一个完整的内存更新系统组成。在那种情况下，甚至没有快照。

洋葱架构只是描述了工件的分离。它们是哪些工件实际上取决于特定要求。

【讨论】：

【解决方案2】：

应用层应该负责。应用程序服务通过编排对域的调用来实现用例。作为用例的一部分创建或修改的域实体必须以一种或另一种形式保存在内存中，以便以后持久化。

执行此操作的典型方法是将它们放入一个工作单元（其实现驻留在基础架构层中）。它跟踪对域实体所做的修改。当应用程序服务结束业务事务时，工作单元会将实体状态转换为可刷新到持久存储的内容。

【讨论】：