有限的上下文实现和设计 [英] Bounded context implementation and design

问题描述

比方说，我有两个有界上下文，即 Shipping Context 和 Billing Context .这些上下文中的每一个都需要了解客户.

Let's say I have two bounded contexts, the Shipping Context and the Billing Context. Each of these contexts need to know about the customer.

在数据级别，客户由数据库中的CustomerTbl表表示.该表包含描述客户的所有必要列.

At a data level, the customer is represented by a CustomerTbl table in a database. This table consists of all the necessary columns that describe the customer.

CustomerTbl中的列(简体):

• Name
• PhysicalAddress
• PaymentMethod

• Name
• PhysicalAddress
• PaymentMethod

运输上下文与Name和PhysicalAddress有关，而计费上下文与Name和PaymentMethod有关.

The Shipping Context is concerned with Name and PhysicalAddress while the Billing Context is concerned with Name and PaymentMethod.

在运输环境中，我对聚合Recipient进行了建模:

In the Shipping Context I have modeled the aggregate Recipient:

• Recipient现在具有Name和PhysicalAddress
的属性/值对象

• Recipient now has properties/value objects for Name and PhysicalAddress

在结算上下文中，我对聚合Payer进行了建模:

In the Billing Context I have modeled the aggregate Payer:

• Payer具有用于Name和PaymentMethod
的属性/值对象

• Payer has properties/value objects for Name and PaymentMethod

Recipient和Payer聚合均被上下文边界完全分隔.他们也有自己的存储库.

Both Recipient and Payer aggregates are completely separated by the context boundary. They also have their own repositories.

1. 使用同一数据库表"具有多个聚合(假设它们在单独的有界上下文中)是否可以接受?

1. Is it acceptable to have multiple aggregates (provided that they are in separate bounded contexts) using the same "database table"?

在更多有限的上下文中可能需要客户数据.这是否意味着每个有限的上下文都有许多聚合，存储库和工厂实现?代码中会有一定程度的冗余.这不会影响可维护性吗?

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?

跨聚合具有共享属性是否可以接受?例如，客户Name属性.这还意味着冗余验证代码吗?

Is it acceptable to have shared properties across aggregates? An example would be the customer Name property. This would also mean redundant validation code?

推荐答案

Q& A

1)使用同一数据库表"具有多个聚合(假设它们在单独的有界上下文中)是否可以接受?

1) Is it acceptable to have multiple aggregates (provided that they are in separate bounded contexts) using the same "database table"?

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

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

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?

不一定，请查看共享内核模式.

3)跨聚合具有共享属性是否可以接受?一个示例是客户名称属性.这还意味着冗余验证码吗?

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?

与问题1相同的答案.关于冗余，一旦有了共享的内核，就可以简单地将验证器类放在其中.

Same answer as question 1. Concerning redundancy, once you have a shared kernel you may simply put your validator classes in there.

优雅的代码不会不必要地使出色的设计原则相互矛盾.通常，有一种方法可以满足这些原则.您只是还没有找到它，因为您对这些原理还不够了解，或者您对问题没有足够的剖析.

Elegant code does not unnecessarily put great design principles at odds with each other. Usually there is a way that satisfies the principles. You simply haven't found it yet, because either you don't understand the principles enough or you haven't dissected your problem enough.

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

这篇关于有限的上下文实现和设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！