2016-08-25 101 views
0

这是建议的方式来实现在下面的例子_customRoleRepository? 以下代码在应用程序服务中执行。DDD库输入参数

var user = _userRepository.GetById(1); 
var customRole = _customRoleRepository.GetById(user.CustomRoleId); 

var user = _userRepository.GetById(1); 
var customRole = _customRoleRepository.GetForUser(user); 
+0

哪些用户和他们的角色被加载? – tomliversidge

+0

@tomliversidge创建身份验证令牌并获取角色权限以将其与该令牌绑定 – Robert

回答

1

鉴于两种选择,我可能会去的第一个,这使通过ID访问的一致性。

如果可能的话,当你加载用户避免另一轮的访问数据库,尤其是如果这是一个常见的操作可能是最好加载自定义角色。这可以作为读取模型来实现。

这是假设你已经正确地模仿你的聚集... :)

+0

有点像CQRS? – Robert

+1

术语可以取决于你与谁交谈:)但是当我们经常使用术语CQRS(命令查询责任分离)时,有一个单独的数据存储区用于读取,这些数据存储区预先准备投放到响应所需的读取模型中。它基于事件流异步保持最新。然而,另一个同样有效的技术是CQS(命令查询分离),即当您有一组查询针对写入模型持久性存储运行标准查询时。查询在应用程序中是_separated_,但是读取的模型并未完全_seregreg_。 –

+0

因此,对于我来说,实现一个简单地将Users表连接到CustomRoles表的读取模型查询,并返回一个读取模型dto就是CQS。而且,如果数据直接发布到UI或API响应数据,我认为这只是一个好主意。如果您打算使用返回的数据与域聚合/实体进行交互,那么您使用存储库所做的更好,因为您将域模型与域模型配合使用,并保持独立的访问策略。 –

0

讨厌这样说,但在DDD的环境,我的答案是没有。

在第一个示例中,角色存储库可以不理会用户域,但这意味着应用程序需要知道获取角色以便将用户ID从用户中提取出来,然后查询另一个存储库。换句话说,应用程序充当用户和角色之间的映射器。

在第二个例子中,角色存储库现在需要了解的用户域。不是很好,但另一方面,应用程序不再需要了解roleId。这很好。这两种方法之间经典的折衷。

但在这两种情况下,应用程序仍然需要两个仓库来获得它的信息。当需要更多关系时会发生什么?存储库的数量可以迅速增长,事情变得一团糟。

在领域驱动设计,你应该尽量想在总根(AR)和域环境方面。对于您的示例上下文,用户是一个AR,角色成为一个孩子。所以,你可能有:

var user = _userFinder.GetById(1); 
var customRole = user.CustomRole; 

这隐藏了大部分从您的应用程序的实施细则,并允许你专注于你的域实体实际上需要做的。

+0

CustomRole代表BC中的另一个AggregateRoot。它有实体(权限)等。多用户可以共享相同的CustomRole。你的建议是将CustomRole作为一个值对象,当CustomRole得到更新时,我必须将该更改传播给该角色中的所有用户? – Robert

+0

同一个bc内的两个ars听起来很麻烦。在你的例子中,我认为角色是一个价值对象。我将有一个不同的bc更新角色,是发送通知告诉用户角色已更改。当然,这很大程度上取决于您是否真的需要处理复杂的业务逻辑。很难在不知道大局的情况下提出具体的建议。 – Cerad

+0

顺便说一句,我认为这些问题得到了更好的回应http://programmers.stackexchange.com/ – Cerad

1

两者都同样有效,这取决于你的需求。 GetForUser会很好,如果你想确保调用代码在你尝试和检索角色之前有一个有效的用户聚合 - 当它确实将customRoleRepository耦合到用户聚合的知识,如果你想要求调用代码有一个有效用户聚合,那么这个耦合有一个目的。

GetByUserIdGetById更加一致,而且具有更少的耦合,因此,如果在你的情况下也没关系调用GetByUserId即使客户没有一个有效的用户聚集,那也没关系。

如果您正在加载ById,我也使用类型的身份valueobjects可以说是相当有帮助的发现提供类型额外的安全水平 - 有什么好处和缺点在这里一些https://stackoverflow.com/a/5377460/6720449谈话,在这里https://groups.google.com/forum/#!topic/dddcqrs/WQ9zRtW3Gbg