公开类似存储库方法的域实体 [英] A domain entity exposing a repository-like method

问题描述

以这个例子为例。 主管域类公开了方法
GetUnderlings（DateTime from，DateTime to），该方法将返回给定期间内由给定主管进行监督的所有人员。 / p>

出于令人愉快的语义原因，该方法应转到此处。但是应该为DDD纯度而去其他地方。那是因为我假设要实现该方法，就需要使用存储库，而将其嵌入域实体中似乎是错误的。在这种情况下，该方法应该在存储库或服务上进行- GetUnderlings（主管主管，DateTime从，DateTime至）

处理这种情况？

编辑：我认为可以这样描述力量：根据OO负责人，我希望我的公共接口实体以公开丰富的面向业务的功能集。但是根据DDD实现原理，此类方法的实现可能最好放在其他位置。以服务为例。

如何解决这种明显的冲突？我可以看到的方式是：

1. 让实体具有对服务或服务接口的引用


2. 总是让客户去服务，而不是直接去实体（结果：失去一致性，并且从面向对象的角度来看完全不酷）


3. 使用域事件（ ？）


4. 使用一些AOP技巧将方法的实现委派给服务。

解决方案

如果 Supervisor 是 Aggregate Root ，则返回<$ c是有效的来自主管的$ c> Underlings 列表，但只是 READONLY 集合，因为 Underlings 超级用户将修改$ c>保留，以将域规则和不变量应用于修改操作。 （不仅是DDD中的基本规则，而且是良好的OOP设计）

Underlings 似乎是历史实体。在大多数情况下（我没有足够的上下文信息来确认您的情况），历史实体不是聚合根和仅 聚合根具有存储库。

请记住，如果检索 Undelings 是针对 UI （不需要对规则和不变量应用操作），您无需在意聚合根，实体等，因为您应该应用CQRS并使用视图服务来检索纯数据（第一范式，而不是汇总根）显示给用户。当用户 UI 触发操作时，您需要检查规则（这意味着应用DDD）；您从存储库中检索 Supervisor ，选中 Underlings （请记住，只读集合）来决定，应用操作并保存更改。

Take this example. A Supervisor domain class exposes a method GetUnderlings(DateTime from, DateTime to) which will return all those people supervised by the given supervisor in the given period.

The method should go here for pleasing semantic reasons. But should go somewhere else for DDD purity. That's because I'm assuming to implement the method one would need to use a Repository, which it seems wrong to embed inside the Domain Entity. In that case, the method should go on a Respository or Service - GetUnderlings(Supervisor supervisor, DateTime from, DateTime to)

How do others handle this scenario?

EDIT: I think the forces can be described like this: according to OO principals, I want the public interfaces of my entities to expose a rich set of business-oriented functionality. BUT according to DDD implementation principals, the implementations of such methods might best be located elsewhere. In a service, for example.

How can this apparent conflict be resolved? The ways I can see are:

1. have the entity have a reference to the service, or service interface
2. Always make the client go to the service, not to the entity directly (result: loss of coherence, and totally not cool from an OO perspective)
3. use "Domain Events" (?)
4. use some AOP trick to delegate implementation of a method to the service.

解决方案

If Supervisor is an Aggregate Root it is valid to return Underlings list from Supervisor but just READONLY collection because Underlings shold be modified by Supervisor to apply domain rules and invariants to the modify action. (basic rule not only in DDD, is just well OOP design)

Underlings seems like a history entity. In most of the cases (I do not have enough context info to afirm this in your case) history entities are not aggregate roots and ONLY aggregate roots have repositories.

Keep in mind that if the retrieve of Undelings is for UI (not to apply an action with rules and invariants) you do not need to care about aggregate roots, entities, etc, because you should apply CQRS and use view services to retrieve plain data (1st normal form, not aggregate roots) to show it to the user. When an action is trigger by the user UI you need to check rules (that means apply DDD); you retrieve Supervisor from Repository, check Underlings ( remember, readonly collection) to take decissions, apply the action and save changes.

这篇关于公开类似存储库方法的域实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！