How to represent bounded contexts?

Question

I mean - physically, in code. Organization of naming, namespaces, folders, assemblies, database/s.

How bounded contexts should interact?

For example, feel free to use classic e-commerce business domain.

Answer 1

I'd say 'it depends'

Some times it might be enough to map your BC entities to the same database and sometimes you might have different databases for your BC's.

IMO, e-commerce might be more of a BC than a complete domain.

I've spent a bit too much time at a whole sales agent where they sold food products.

So the domain was "whole sales" and the bounded contexts was, inventory, purchase, sales, invoicing, product catalog and e-commerce (maybe I use the wrong english wording here)

Each of these BC's knew about "products" but they all had their different view of a product.

e.g. Purchase might have a product entity with vendor information, purchase price etc attached to it.

While a product in the e-commerce domain would be modelled from a customer point of view, it would have information relevant for the customer that views it, their specific price etc.

the e-commerce BC would get its product information from multiple sources; product catalog and sales. where the base information is from the product catalog and customer specific prices are from sales.

So the product repository in the e-commerce BC might do context-mapping from the other BC's (via services of some sort, most likely web or wcf in my case) to construct our e-commerce product entity)

Personally I do model this as separate assemblies, I would have an e-commerce Model and a sales model.

Most of the information in my e-commerce model would come from external sources and wouldnt be locally persistent. Only things like shopping-cart would be locally persistent since those objects are owned by the e-commerce model.

Once a customer tries to complete their purchase, I would construct a pre-order from the shopping cart and then pass that to the sales BC. Either by a direct service call or through a message queue.

So in short, I tend to build my systems around a specific BC and only interact with other BC's through services.

I know that alot of people do put their BCs in the same assemblies and use multiple BC's from the same app etc. But I just find it odd why an app for a specific purpose should know about multiple contexts. I'd rather make it know about only one context and then pass whatever data I need over to other apps.

Answer 2

I certainly agree that it all depends, but there are some guidelines that can/should be followed. The purpose of bounded contexts is, well, boundaries. Boundaries that separate on part of application from another by introducing a well defined contract (interface).

I tend to treat BCs like Services in SOA. For me it means ideally they are physically separate applications (OS processes/IIS websites). Binaries are also separated of course. All communication between BCs is ideally asynchronous. In real world it is hardly possible, but at least I don't allow cross-BC transactions for they are pure evil.

Hope that helps.