Entities across bounded contexts in Domain-Driven Design

旧时模样 提交于 2019-12-03 11:27:41

From http://msdn.microsoft.com/en-us/library/jj554200.aspx :

Bounded contexts are autonomous components, with their own domain models and their own ubiquitous language. They should not have any dependencies on each other at run time and should be capable of running in isolation.However they are a part of the same overall system and do need to exchange data with one another.

If you are implementing the CQRS pattern in a bounded context, you should use events for this type of communication: your bounded context can respond to events that are raised outside of the bounded context, and your bounded context can publish events that other bounded contexts may subscribe to. Events (one-way, asynchronous messages that publish information about something that has already happened), enable you to maintain the loose coupling between your bounded contexts.

If they are strictly separate, I would make them strictly separate. Two different classes in different namespaces. Each have different attributes.

If HR creates an HRM.Employee, an event could be raised that Accounting picks up and creates an Accounting.Employee.

If more than one context is necessary, definitely some things can be modeled as an entity in some contexts and a value object in another. Translating from an entity to a value object is usually straightforward, but from a value object to an entity may not be so straightforward. From Domain Driven Design, p. 337:

The translation mechanism is not driven by the model. It is not in the bounded context. (It is part of the boundary itself, which will be discussed in context map.)

If the Human Resources context ever needs to ask the Accounting context a question about a particular employee, it would become a confusing question.

I guess I would not use the same entity in both context. They are supposed to be bounded. What if I have to change my employee class for the needs of one context?... the "supposed to be bounded context" is not that bounded anymore.

I would use a value object. The trick is to define properly the value object. I see those are equivalent to "Data Types" object, like an integer is an integer. This is challengeable of course (int16,int32...). But let's assume it is the case. Is Employee a good candidate for a value object?.... I do not think so :(... You might not need the same set of information for Employee in bounded context. In another name the identification information of the employee is a better candidate (firstname, lastname, middlename...) This you could reuse in bounded context.

Now should the service layer return this value object?... Personnaly I would not do it. I would prefer to have this reusability defined in my repositories. Sharing mappings in Nhibernate or sharing the same projection/mapper class.

Hope this helps :)

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!