问有界上下文实现与设计

EN

问与答

( 1)使用相同的“数据库表”拥有多个聚合(前提是它们在不同的有界上下文中)是否可以接受？

• 只要您遵循管理共享状态的严格策略，我就可以接受它。
• DDD是可以接受的，因为域被认为比数据更重要。
• 这是可以接受的，你的客户，只要它完成工作，而不引入(太多)隐藏成本。

2)在更多有限制的情况下，可能需要客户数据。这不意味着每个有限制的上下文都有许多聚合、存储库和工厂实现吗？代码中将存在一定程度的冗余。这不影响可维护性吗？

不一定要看一下shared kernel pattern。

3)拥有跨聚合的共享属性是否可以接受？一个例子是customer属性。这也意味着冗余验证代码？

与问题1一样，关于冗余，一旦有了共享内核，您就可以简单地将验证器类放在其中。

关于你在干爽和DDD之间的冲突：

优雅的代码并不会不必要地使伟大的设计原则相互冲突。通常有一种满足原则的方法。你只是还没有找到它，因为要么你对原则不够了解，要么你没有充分剖析你的问题。

(如果这听起来是教条的话，那是因为软件工程实际上是一种宗教)

答案：

1.如果聚合体及其存储库是只读的，则为是。如果在没有通知其他上下文的情况下单独更改模式或数据，那么在有界上下文之间共享存储和模式可能是一个问题，但我认为在这种情况下这不是一个大问题。

但如果收款人和付款人是可编辑的，则情况就不同了。很可能有人可以修改它们，这会在有限制的上下文中产生影响。例如，客户可能需要更改特定送货订单的地址，但是共享裁剪表可能会在没有通知的情况下更改客户发货订单的所有地址。所以最好为它们使用不同的存储空间。

2.不同的有界上下文需要客户的不同方面。我认为只依赖必要的数据是一个很好的实践，因此聚合抽象可能是不同的。潜在的可维护性问题可能发生在实现端(主要是因为重复代码)。因此，我们可以引入一个额外的组件，返回客户的所有方面，并在其上构建有限制的上下文特定适配器。