Limited Context Size

Question

I started to learn the principles of DDD, and I'm currently trying to understand the concept of limited context. In particular, how do you decide how big (or small) it should be? Yes, I know how possible and how necessary (according to Vaughn Vernon).

Let's say I had to create a blog. Then I could say that there are 3 limited contexts: 1) Front Page (with the latest articles, no comments) 2) Discussion (one article, including comments) 3) Article Composer (where I compose the article).

However, this does not seem to be correct (the ubiquitous language is the same for all of them), it seems that I proceed from the front end point of view and still think from the point of view of models of views or something else.

Can someone point me in the right direction?

Answer 1

Try to look at the whole domain from different points of view, as an article editor, you will probably use sentences, such as creating a draft article, publishing an article, as an article that you read in the example, read the article and the comment in the topic. Along with building the language of your domain, you will identify the entities and their behavior, some of them will appear in only one perspective, some will appear in both, but you will distinguish them by their behavior. Your domain language shows the boundaries of each perspective, which you implement as a limited context.

Answer 2

A blog is not a good example of using multiple restricted contexts. This is not really a "big enough" example of software to guarantee their definitions. DDD and BC truly target large / complex enterprise software systems.

As you say, aggregates always have the same meaning in your three examples.

I gave this example of a limited context in a previous answer, which I hope explains to BC and when to use them: Limited contexts and aggregate roots

Answer 3

The best example I've read of subdomains is the following.

Just explore the real company! Each department involved in the business process may have its own subdomain. In an ideal world, each subdomain has its own limited context in your implementation. You have to ask yourself if the company needs a new department for this? Is it really that much?

British Columbia should be large enough to describe the department of the company. A typical example is an online store in which you have a domain of the main domain for purchases and billing, delivery and storage of subdomains. Having a multi-tenant lease and so many aspects - as described in the previous answer - is not enough. A blog with an author and multiple readers does not require multiple departments, so you can solve this with one limited context. You can have multiple modules in a limited context if you think you have medium-sized structures in a limited context.