如何检查洋葱架构领域层中的业务逻辑
本文关键字：业务 何检查 检查 洋葱 | 更新日期: 2023-09-27 18:03:13
我一直在做网站开发，最近开始用MVC创建一个电子商务项目。
我决定用洋葱架构来开发它。据我所知，我的逻辑分为两个不同的领域:应用逻辑和业务逻辑。
如你所知，我有两个地方实现这些逻辑:用于业务逻辑的域层和用于应用逻辑的服务层。而且根据洋葱体系结构， 领域层与上层如基础设施层没有关系。
所以我必须在领域层检查这些业务逻辑，并根据情况抛出适当的异常。例如，"拥有积极的产品价格"就是一个商业逻辑。此逻辑不需要与数据库有关系。但是，如果我想检查"duplicate Name for product"该怎么办?我确信我不应该在服务层中检查此逻辑。我应该在哪里以及如何检查这些逻辑。
如果我必须有一个验证层，如何使这一层的关系?谢谢你的回复。
我通常在域层定义存储库接口，例如ICustomer, IOrder，…具体对象CustomerRepository, OrderRepository，…在自己的基础设施层。如果域层中的方法在正常执行过程中需要数据库中的某些内容，那么我就从服务层向该方法注入适当的存储库接口，只使用我需要的数据库方法。
有时最好为功能定义自己的接口，例如ICanCheckForDuplicateNames具有CheckForDuplicates(string name)方法(该接口位于域层)。在服务层中，我将实例化一个实现ICanCheckForDuplicateNames的对象(该对象在基础设施层中定义)，并将其作为参数传递给域对象。
如果您不需要数据库方法的结果，而只是需要调用它，例如Log(string message)，那么您可以在领域模型中定义一个事件并在执行期间引发它，服务层将处理它。通过这种方式，您不需要从服务层向域层类方法传递任何内容。
DDD的核心概念之一是聚合——本质上是一个实体或一组实体，它们可以以事务一致的方式强制执行一组[不变量]。
不变量可以定义为在任何时候都必须为真的业务规则，除了在特殊时间，例如在处理业务事务时。
然而，更具体的定义是查看聚合的不变量——这些是在任何时候都被强制执行的业务规则——在单个聚合或操作中。这意味着该不变量必须基于聚合中包含的数据或通过命令或方法参数传递给聚合的数据来强制执行。 描述这一点的一种方法是在聚合的一致性边界内强制执行不变量。它被称为一致性边界，因为通过遵循DDD建议，每次数据库提交只修改一个聚合，数据一致性只在该边界内得到保证。参见http://www.informit.com/articles/article.aspx?p=2020371&seqNum=1，有一篇关于聚合和不变量的优秀文章。
在整个系统中强制唯一约束是一个常见的需求——但是如果你仔细想想，它不可能是单个聚合的责任来强制唯一名称约束，因为它需要知道聚合的所有其他实例来检查——因此违反了一致性边界的原则。
有几个方法可以解决这类问题:
接受规则可能并不总是被执行，但它总是"最终"被执行(一个称为最终一致性的概念)。
- 您可以通过名称设置引发事件，然后触发逻辑执行以检查重复和标记或警报，以便UI可以提请用户注意需要注意的项目以纠正重复的名称。
采取务实的方法，确定在聚合范围之外最有效地执行此类规则的地方
- 。强制惟一约束的传统且非常成功的地方是在数据库本身—大多数rdbms允许在字段上指定惟一约束。由于唯一约束将在检查聚合名称的数据库事务范围内进行检查，因此这确实为该业务规则提供了原子一致性。
- 此选项仅限于所有数据在一个数据库中的情况-如果您已经进行了分片，则可能需要采用第一个选项
老实说，第二种选择是我总是为"普遍唯一"规则做的——如果它们真的是必需的——并且数据集大小是这样的，我希望一个数据库。然而，第一步是质疑它们是必需的假设，并检查与聚合相关联的用户故事，以了解真正的用户需求，以及他们将容忍的最终一致性级别。