大佬教程收集整理的这篇文章主要介绍了域驱动设计 – 很少有人将有关非根实体的引用传递给外部对象，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
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)
它主要是Aggregate root(部分是通过实体)还是外部对象(接收瞬态引用)的责任,以确保不修改传递的实体？如果是后者,那么这个聚合的一致性是不是真的受到了开发外部对象的人的摆布？
图2b)
我假设在大多数情况下,一旦操作完成,外部对象的责任就是摆脱引用？
1b)它可以采用任何一种方式,具体取决于用例.财产只是伪装的一种方法.
2a)这是正确的,这就是为什么最好确保传递的对象不被修改,而是以不可变的方式使用.而且,被传递的实体本身仍然可以保持一定程度的完整性.
2b)正确,你有责任确保这一点.就像你必须确保给定值对象是不可变的(如果需要),你必须考虑传递引用的完整性.
其中大部分都是一般性指导原则,因为它会产生“良好行为”,易于推理,并且易于制作一致的聚合.
2a)鉴于编程语言的局限性,聚合可以保护自身的程度有限.因此,需要“人为干预”,特别是在像这样的更复杂的情况下.确实,总量可能会受到另一个的支配,这就是为什么这些指导方针到位的原因.
2b)是的.外部对象可以使用另一个聚合的内部实体,但是它的引用应该是瞬态的 – 这意味着它不会被持久化.
以上是大佬教程为你收集整理的域驱动设计 – 很少有人将有关非根实体的引用传递给外部对象全部内容，希望文章能够帮你解决域驱动设计 – 很少有人将有关非根实体的引用传递给外部对象所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。