I've started learning the principles of DDD and I'm currently trying to get a grasp of the concept of a bounded context. In particular, how do you decide just how big (or small) it has to be? Yeah, I know, as small as possible and as big as necessary (according to Vaughn Vernon).
Let's say I were to model a blog. I could then go and say there are 3 bounded contexts involved: 1) Front Page (featuring the most recent articles, no comments shown) 2) Discussion (a single article including comments) 3) Article Composer (where I compose an article).
However, this doesn't feel right (the ubiquitous language is the same for all of them), it seems as if I'm coming from a front end point of view and am still thinking in terms of view models or something.
Could anyone please point me in the right direction?
Try to look at your whole domain from different perspectives, as an editor of article, you probably will use sentences like creating a draft of an article, publishing an article, as an article a reader you will in example read article and comment on it. Alongside building your domain language you will identify entities and their behaviour, some of them will appear only in one perspective, some will appear in both, but you will distinct them by their behaviour. Your domain language shows you the boundries of each perspective, that you implement as a bounded contexts.
A blog is not a good example for use of multiple bounded context. It's not really a "big enough" software example to warrant their definitions. DDD & BC's are really aimed at big/complex enterprising software systems.
Like you say, the aggregates always have the same meaning in your 3 examples.
I gave this example of Bounded Context in a previous answer, which I hope explains BC's and when to use them: Bounded Contexts and Aggregate Roots
The best example I read by subdomains so far is the following.
Just examine the actual company! Each department taking part in the business process can have its own subdomain. In an ideal world each subdomain has its own bounded context in your implementation. You should ask yourself whether the company needs a new department to do this? Is it really that big?
The BC must be big enough to describe a department of a company. A typical example is a webshop, where you have a shopping core domain and invoicing, delivery and storage subdomains. Having multi-tenancy and so multiple aspects - as a previous answer described - is not enough. A blog with an author and a few readers does not require multiple departments, so you can solve this with a single bounded context. You can have multiple modules in your bounded context if you think you have medium size structures in your bounded context.
来源：https://stackoverflow.com/questions/30257603/size-of-a-bounded-context