在数据级别,客户由数据库中的CustomerTbl表表示.该表包含描述客户的所有必需的列.
CustomerTbl中的列(简化)：
>名称
> PhysicalAddress
>付款方式
运输上下文涉及到名称和物理地址,而帐单上下文涉及到名称和付款方式.
在运输环境中,我已经建模了总收件人：
>收件人现在具有Name和PhysicalAddress的属性/值对象
在帐单上下文中,我已经建立了总体付款方：
> Payer具有Name和PaymentMethod的属性/值对象
收件人和付款者汇总都通过上下文边界完全分隔.他们也有自己的仓库.
问题：
>使用相同的“数据库表”,有多个聚合(只要它们位于单独的有界上下文中)是可以接受的吗？
>客户数据可能需要在更多有限的上下文中.这不意味着每个有界的上下文的许多聚合,存储库和工厂实现？代码中会有一定程度的冗余.这不会影响可维护性吗？
>跨聚合共享属性可以接受吗？一个例子就是客户名称属性.这也意味着冗余验证码？
解决方法
1) Is it acceptable to have multiple aggregates (provided that they are in separate bounded contexts) using the same “database table”?
>只要遵循管理共享状态的严格策略,我可以接受.
> DDD是可以接受的,因为域被认为比数据更重要.
只要客户完成工作,不用引入(太多)隐藏的成本就可以接受你的客户.
2) Customer data would likely be needed in many more bounded contexts. Would this not mean many aggregate,repository and factory implementations for each bounded context? There will be a degree of redundancy in code. Does this not effect maintainability?
不一定,看看shared kernel pattern.
3) Is it acceptable to have shared properties across aggregates? An example would be the customer Name property. This would also mean redundant validation code?
关于冗余问题,一旦你有一个共享的内核,你可以简单地把你的验证器类放在那里.
关于DRY和DDD之间的冲突：
优雅的代码不会不必要地将伟大的设计原则相互矛盾.通常有一种方法可以满足原则.你根本没有找到它,因为你不足够理解原则,或者你还没有解释你的问题.
(如果这听起来教条主义是因为软件工程实际上是一种宗教)
