困惑，关于Cargo中的Voyage实体

supernavy
在Cargo的例子中，Voyage被做为一个实体引入进域模型, 但是在Cargo的例子中，Voyage是个非常简单的实体，只有只读的操作。在实际的生活中，我感觉Voyage肯定不是这么一个简单的实体，很可能有一个已经存在的专门的系统在维护。在Cargo系统中包含的Voyage应该是外部系统中的一个映射，在Cargo中应该是根据VoyageId通过VoyageService来查询。这样的话是不是就不应该在Cargo系统中存在Voyage这样一个实体，而仅仅是个查询得到的值对象呢？那么Cargo模型要做什么样的调整？
同样的问题也对Location实体存在，我想应该有个共享的系统来维护Location，在Cargo中又维护了自己的Location实体。
归根到底，为什么把一些通用的共享的东西都建模成当前系统的实体，这其实不符合实际的情况。是不是应该从一开始就把这些共享的东西建模成外部系统的实体依赖比较好？怎么体现在模型中呢？
banq 2013-09-16 17:02
2013-09-16 16:55 "@supernavy
"的内容
是不是应该从一开始就把这些共享的东西建模成外部系统的实体依赖比较好 ...

这是上下文boundedcontext限制，每个上下文有自己的聚合，聚合之间不能相互直接引用，如果想使用另外一个上下文中某些实体，只能通过值对象共享等方式。否则有界的上下文就变成无界了，到处相互直接引用，蜘蛛网了。