1)
a)为什么外部对象在单个操作的持续时间内具有引用(对于内部实体)是可接受的,但在两个操作的持续时间内保持该引用是不可接受的？我的观点是,如果在两次操作的持续时间内保持参考是不好的,那么在一次操作的持续时间内坚持它可能同样糟糕吗？！
b)假设SomeRootEnt Aggregate root将内部实体SomeIntEnt的瞬态引用传递给外部对象,外部对象应如何请求SomeIntEnt？通过在根上调用特定方法 – 例如SomeRootEnt.BorrowMeIntEnt(…) – 或者root应该直接暴露内部实体作为其属性(例如SomeRootEnt.SomeIntEnt)？
2)
a)假设SomeRootEnt root将对内部实体SomeIntEnt的引用传递给外部对象,而外部对象又对SomeIntEnt进行了一些修改,那么这并不意味着root无法对这些修改应用适当的不变逻辑(即root can’检查修改过的SomeIntEnt的完整性？
b)同样,根据我的理解,至少在完成单个操作后,root也无法强制外部对象删除对内部实体的引用？
谢谢
更新：
图2a)
That is correct,which is why it is best to ensure that the passed
object isn’t modified,but is used in an immutable way. Moreover,the
passed entity can still maintain a degree of integrity on its own.
它主要是Aggregate root(部分是通过实体)还是外部对象(接收瞬态引用)的责任,以确保不修改传递的实体？如果是后者,那么这个聚合的一致性是不是真的受到了开发外部对象的人的摆布？
图2b)
Correct and it is your responsibility to ensure this. Just like you
have to ensure that a give value object is immutable (if needed) you
have to consider the integrity of passed references.
我假设在大多数情况下,一旦操作完成,外部对象的责任就是摆脱引用？
解决方法
1b)它可以采用任何一种方式,具体取决于用例.财产只是伪装的一种方法.
2a)这是正确的,这就是为什么最好确保传递的对象不被修改,而是以不可变的方式使用.而且,被传递的实体本身仍然可以保持一定程度的完整性.
2b)正确,你有责任确保这一点.就像你必须确保给定值对象是不可变的(如果需要),你必须考虑传递引用的完整性.
其中大部分都是一般性指导原则,因为它会产生“良好行为”,易于推理,并且易于制作一致的聚合.
UPDATE
2a)鉴于编程语言的局限性,聚合可以保护自身的程度有限.因此,需要“人为干预”,特别是在像这样的更复杂的情况下.确实,总量可能会受到另一个的支配,这就是为什么这些指导方针到位的原因.
2b)是的.外部对象可以使用另一个聚合的内部实体,但是它的引用应该是瞬态的 – 这意味着它不会被持久化.
