How to represent bounded contexts?

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.

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.

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.