基本集合问题 [英] Basic Aggregate Question

查看:155
本文介绍了基本集合问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

允许的聚集是不是根中引用的实体客户端code?我有一个故事(根),团队(实体)和 TeamMember (实体)。我想,如果 AddTeamMember 方法属于对团队故事

Is client code allowed to reference entities within an aggregate that is not the root? I have a Story (Root), Team (Entity) and TeamMember (Entity). I am trying to decided if the AddTeamMember method belongs on the Team or Story.

我想我的例子是一个小错误导致。我真正的问题是一个聚集之内即可客户端code基准非根实体?

I guess my example was a little mis-leading. My real question is can client code reference non-root entities within an aggregate?

推荐答案

我的意见 - 它不应该。被提及的属于某个聚合实体意味着您可以在调用该实体的方法不完全汇总方面,如果你允许,你永远无法知道你的整个集合是有效的,一致的。

My opinion - it should not. Having a reference to an entity that belongs to certain aggregate means that you are able to invoke a method on that entity without full aggregate context and if you allow that, you can never be sure if your entire aggregate is valid and consistent.

简单的例子:

    public class MyAggregateRoot
    {
        protected MyEntity entity;

        public void BuildUpAggregate()
        {
            ValidateSomeRule();
            LoadEntityFromDatabase();
        }

        public MyEntity MyEntity
        {
            get 
            {
                VerifySomeOtherRule();
                return entity; 
            }
        }
    }

正如你所看到的,同时建设,并通过聚合根检索myEntity所,我们有两个验证规则检查 - 如果你将允许客户端引用myEntity所直接,总可能会随时改变与客户端检索到的实体上执行的操作它,所以检查将不再是有效的,但你不会的事件是知道这个事实。换句话说,你的汇总会出现不一致,可能无效。

As you can see, while building and retrieving MyEntity via aggregate root we have two validation rules checked - if you would allow the client to reference MyEntity directly, the aggregate might change in time between client retrieved the entity and performed an operation on it, so the checks would no longer be valid, but you wouldn't event be aware of this fact. In other words, your aggregate would be inconsistent and potentially invalid.

在一般情况下,在DDD有一个较强的规则,指出所有访问实体在聚合应该通过从聚合根遍历进行 - 这条规则是完全是为了聚集体的稠度的

In general, in DDD there's a strong rule that states that all access to entities in aggregate should be performed by traversing from the aggregate root - this rule is exactly for the sake of consistency of aggregates.

这是说,你的客户可以参考是一个实体的投影 - 一种,它包含仅用于显示和决定某个动作是否在目前的情况下提供数据的只读副本。你可以再进一步,聚集来自一组实体的数据到一个投影,调整它一点点,所以这将是针对用户界面的需求。我发现这个技术不是让我的用户界面,以决定如何在商业领域应当效仿相当有用的。

That said, what your client can reference is a projection of an entity - a sort of read-only copy that contains only data required for displaying and deciding whether a certain action is available in current context. You can go even further and aggregate the data from a set of entities to a single projection, tune it up a little, so it would be tailored to the requirements of UI. I found this technique quite useful for not allowing my UI to decide how the business domain should be modeled.

这篇关于基本集合问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆