具有相关对象的验证/业务规则
假设我有一个具有嵌套属性的类：root.propA.propB.propC，其中每个 prop 由一个类表示：propA by classA 、propB by classB、propC by classC 和 root = 聚合。
假设几个对象相互关联：root1 --> （root2，root3），root2 --> root4，root4 --> root1。
在 DDD 中，“验证逻辑”/“业务规则”应该位于每个类中。我想在每个类中完整地执行规则。例如： propC 由 classC 表示 - 我想要一个上下文：
root1, root2, root3, root4（因为它们是相关的） ：例如，我想确保只有 1propC具有特定值- 我想要
propC的父级：例如，我想检查父级是否有一定的值（应该可以使用实体框架作为导航财产？）
如何解决？
- 在每个类的CTR中注入一个上下文，然后设置相关
root对象的属性？ - 每个类都有一个相关
root对象的列表？
我找不到 DDD 和相关对象的示例
Assume I have an class with nested properties: root.propA.propB.propC, where each prop is represented by an class: propA by classA, propB by classB, propC by classC and root = aggregate.
Assume that several objects correlate to each other: root1 --> (root2, root3), root2 --> root4, root4 --> root1.
In DDD the “validation logic” / “business rules” should be in each class. I want to full context in each class for executing rules. For example: propC is represented by classC – there I want a context with:
root1, root2, root3, root4(since they are related): For example, I want to ensure, that only 1propChas a certain value- I want the parent of
propC: For example, I want to check that the parent has a certain value (should be possible with entity framework as navigation property?)
How can that be solved?
- Inject a context in CTR of every class and set the properties of related
rootobjects afterwards? - Every class has a List of related
rootobjects?
I couldnt find examples with DDD and related objects
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 DDD 中，聚合是原子验证的相关对象的集合em> 由业务层。为了更容易实现，验证逻辑代码被拆分到所有类（根、classA、classB、classC）中，但该命令最终会更新聚合的状态，然后验证该目标状态是否违反任何业务规则。一旦经过验证，它将状态持久性委托给基础设施层，这将更新事务中的存储。
根聚合实例是在事务内部或用于业务规则验证时无法跨越的边界。如果您需要跨多个聚合实例强制执行任何业务规则，那么您可以：
聚合是原子的，因此您始终操作根对象和所有依赖属性。 root.propA.propB.propC 的父级是 root.propA.propB，因此您可以访问它。您可以向 ClassC 添加导航属性，以便您可以根据需要从 propC 访问 propB。
但需要注意的是：实体框架是一个 ORM，它用于基础设施层中的持久性，并且是工作单元模式实现。它不适用于域建模，因为使用 EF 将域状态持久保存到 RDBMS，而不是将状态存储在事件源存储库、通过 FTPS 访问的 xml 文件或 nosql 文档数据库中，这是基础架构实现细节。
匹配域模型和持久性模型仅适用于非常简单的应用程序。您很快就需要将业务模型的复杂性限制为较小的多义设计，而不是阅读整个持久性存储。
您可以选择在哪里划定将重叠聚合数据合并到共享存储以及将它们拆分为每个服务的不同数据库之间的限制。此限制称为有界上下文。
In DDD, an aggregate is a collection of related objects that are validated atomically by the business layer. The validation logic code is split across all classes (root, classA, classB, classC) for easier implementation, but the command ultimately makes updates to the aggregate's state and then validates that this target state does not violate any business rule. Once validated, it delegates the state persistence to the infrastructure layer, that will update storage in a transaction.
The root aggregate instance is a boundary that cannot be crossed inside the transaction or for business rule validation. If you need to enforce any business rules across multiple aggregate instances, then you may:
The aggregate is atomic, so you always manipulate the root object and all dependent properties. The parent of root.propA.propB.propC is root.propA.propB so you can access that. You may add a navigation property to ClassC so you can access propB from propC if you want.
A word of warning though: Entity Framework is an ORM, it is used for persistence in the infrastructure layer, and is a unit of work pattern implementation. It does not apply to domain modeling, because persisting your domain state to a RDBMS with EF rather that storing the state in an event sourcing repository, an xml file accessed through FTPS, or a nosql document database, is an infrastructure implementation detail.
Matching your domain model and your persistence model works only for very simple applications. You will quickly need to restrain the complexity of your business model to smaller polysemic designs instead of reading your whole persistence store.
It's up to you to choose where you draw the limit between merging overlapping aggregates data into a shared storage, and splitting them into different database-per-service. This limit is called a bounded context.