Bounded Context in EntityFramework CodeFirst

Question

I have searched a lot about bounded context and I know it is a pattern in Domain Driven Design, and it is for dividing our large model into smaller models using database context but it makes me a little bit confuse. in fact I don't know what exactly it does? and what are benefits of using this pattern
please help me to understand this pattern.

Answer 1

Bounded Contexts are not necessarily about breaking a large model into smaller models but rather for identifying distinct domain models in you business. Each BC should have its own data store. A BC can make use of the data from another BC in various ways (anti-corruption layer, value objects).

So you may have an Asset BC, Warehousing BC, Invoicing BC, Accounting BC, or CRM BC. The advantage is that you can focus on one area at a time. It is probably somewhat tricky to get right and identifying the boundaries requires an intimate knowledge of the various domains so the domain experts are invaluable in getting this done. The difficulty is on par with identifying aggregate roots.

The big benefit is that if you get the decoupling correct your maintenance is going to be easier. It is the right thing to do :)

Answer 2

I'll give an example since others have given excellent explantations.

Imagine you made a phone call to a travel agency, the operator in the call center picked up your call, he/she probably can answer starting with "Dear Mr Doe"(Imagine this is your character's name:John Doe) if you had called them before and your name was recorded and binded with your phone number.

Seconds later, I made a call to the same travel agency, the operator answer with "Dear Mr Zhou".

The CRM told the operator about our surnames, but there is some tricky here: I'm a chinese, so my name is Zhou hippoom (Surname first), but most western names are Surname last(John Doe). For sake of this, the CRM uses this model below:

Thus, the operator could spot customers' surname directly, no matter the order.

On the other hand, The operator needed my full name when I wanted to book an air ticket. The full name given must be the same as that on my passport(So that I can check in at the airport). The air booking system uses the model below:

There are two PersonName s in the above example, you could use a canonical model of course, but it's just not easy to use for both of them:

1) use fullname in CRM makes the operator to guess which one is the surname

2) use surname/firstname in air booking makes no sense because it doesn't matter as long as they're the same as that on the passport.

A bounded context specific model works better in this case:CRM.PersonName and AIR_BOOKING.PersonName

Someone told me before: Something is not easy to use if it is designed as generic.

Answer 3

A bounded context arises where one ubiquitous language is consistent.

The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.

Read this article, it provides a helpful analogy.

Answer 4

Julie Lerman provides a pretty good explanation of the Bounded Context.

I'd recommend reading the following http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

Bounded context has a lot advantages as far as the n-tier architecture (with EF) is concerned:

• Readability
• Scalability
• Performance ...and others.