Re: Bounded Contexts, Domains (Core, Supporting, Generic), and data imports

Okay, so BCs are logically separate, but can also be physically separate, which is actually how I have treated them in the past, but recently came across a sentence in IDDD that I mistook for asserting that BCs are only physical: "We've also drawn some connections between logical Subdomains and even physical Bounded Contexts..." (Kindle edition, position 1531). Reviewing this I now see that Vaughn was simply providing a specific example for a fictitious domain.

For the most part, the relationship the Training Context has with HR Context is a Customer/Supplier (HR being the Supplier), although all I get is that database feed/link. I say "for the most part" because it is not always an easy or timely process to get the feed changed for the downstream (Training) BC.

Correct me if I'm wrong, but communication between BCs does not *have* to involve events, nor do I *have* to duplicate data into another BC, unless the BC requires it. For example, the HR Context gives me access to *active* employees only. Once they are no longer an employee, I do not see them at all. However, the Training Context has a recordkeeping subdomain (arguably the core domain, and arguably its own BC), that has to allow a user of the application (with proper permissions of course) to go in and lookup an employee and see their record history.

Ray


--- In [email protected], Michael Brown <mbrown@...> wrote:
>
> BCs don't have to be physically separated, it could just be a logical separation. Although they could be deployed separately. But you are correct, there should be only one "owner" of the information within a BC and other BCs can use operations exposed by others to retrieve and manipulate the information stored.
> 
> In your specific case, you can develop the supporting contexts within the Training app as if they were separately deployed. Create a service layer around the HR Context that the Training App uses to interface with the yet to be developed HR App. In the future, the HR App could be separated and the Service layer could be exposed as a true service.
> 
> --Mike
>




------------------------------------