英文:
How do you model & facilitate this functionality in DDD?
问题
我正在开发一个使用干净架构、CQRS和遵循领域驱动设计原则的.NET + EF Core系统。
要描述我的问题，让我们使用汽车经销商作为一个隐喻。
我有两个有界上下文，让我们称它们为销售和服务。我有一个第三个上下文称为用户。
当一辆车被销售时，在销售上下文内执行类似的代码 - 需要“当前用户”来存储诸如谁销售了车辆之类的信息。
当一辆车被维修时，类似地，存储在用户模型上的信息将包括用户是否可以授权对车辆进行某些维修工作，或者是否需要咨询主管。
用户领域对象在用户领域中定义，但正如我们的一些代码库当前实施的那样，该对象也在销售和服务上下文中引用，如以下示例：
public class VehicleService {
// 实例属性
public void AuthoriseService(User user) {
// ... 检查用户是否可以授权维修服务的代码
}
}
这样做是否可行？每个上下文是否应该有自己的用户定义，并具有独特的基础结构来填充它们，尽管它们访问与用户上下文相同的表格？
英文:
I'm working on a .NET + EF Core system which uses clean architecture, CQRS and follows Domain Driven Design principles.
To describe my problem, let's use a car dealership as a metaphor.
I have 2 bounded contexts, let's refer to them as Sales and Service. I have a 3rd context called User.
When a vehicle is sold, such code is executed within the Sales context - and the 'current user' would be needed to store such information like who sold the vehicle.
When a vehicle is serviced, similarly, information stored on a User model would include a 'limit' as to whether the user can authorise certain repairs to be conducted on a vehicle, or whether they would need to consult a supervisor if not.
The User domain object is defined within the User domain, however as some of our codebase currently has it implemented, this object is also referenced in places like the Sales and Service contexts, like such an example:
public class VehicleService {
// instance properties
public void AuthoriseService(User user) {
// ... Code to check if service can be authorised by user
}
}
Is it acceptable to do so? Should each context have their own User definitions, and unique infrastructure to populate them despite them accessing the same table as the User context?
答案1
得分: 1
在我看来，将实体从一个上下文分享到另一个上下文并不是一个好主意，最好在不同的上下文中拥有独立的用户实体。
有界上下文应该尽量松耦合，例如，您有上下文A和B，因此上下文A中的用户实体可能与上下文B中的用户实体不同。请查看这篇文章。
与此同时，要在不同上下文之间进行通信，您需要使用事件，特别是如果您正在使用CQRS。因此，当汽车出售时，应发送“CarSold”事件，并且所有对此事件感兴趣的服务都应通过更新其领域来处理它。想象一下，所有有界上下文都位于独立的微服务中，当您没有共享的代码库时，您将如何实现它。
英文:
In my opinion it is not good to share entities from one context into another context it is better to have separate user entity in different context.
Bounded contexts should be as much as possible loose coupled
for example you have Context A and B so the User entity in context A could be different than in context B check this article
In the same time to communicate between the context you need to use events especially if you are using CQRS. So when Car sold the event CarSold should be send and all the services who interested into this event should handle it by updating their domain. Imagine all your bounded context it is in separate micro-services. how would you implement it when you don't have shared code base
答案2
得分: 0
使用CQRS设计，你会有一些重叠。这是可以预料的。你的跨领域对象可以分别定义，并在不同领域中同时使用，但最好使用接口，以便在必要时可以更改不同领域之间的基础实现。
英文:
With CQRS design, you will have some overlap. This is to be expected. Your cross-domain objects can be defined separately and used concurrently in different domains but it is best to use an interface so that you can change the underlying implementation between domains if necessary.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论