CQRS / DDD: Example Dummy Blog / Article / Category / Tag

Question

Continuing to delve into the experiment for implementing CQRS, I decided to start from my blog from scratch and use it as a Sandbox.

I read a lot about a limited context, it seems to me that this is the most delicate approach in all of this, and perhaps the most difficult to explain and apply in a real project.

Fortunately, my domain here is very simple ,-)

I am trying to define various limited contexts and determine which model becomes the cumulative root in each of these contexts.

Domain rules are very simple:

• When a writer creates a post blog, he MUST choose a category to save his message in and he can select multiple tags to improve post visibility

• When a reader visits a blog, he can browse blogs for category posts or tags . >

Only with these rules we already get a few limited contexts, am I right?

• The user (writer) creates the context of the message. In this context, Post is the cumulative root.

• The user (reader) views messages by category. In this context, a Category is an aggregated root.

• The user (reader) views messages by tags. In this context, well, I'm not sure ...; -)

I think correctly?

Given that I am (right), I wonder, in the implementation of this, who is responsible for creating different objects and relationships?

Take the context in which a user, for example, creates a new blog post, I really don’t know where I should create instances of tags and whether I should create relationships between the Mail and its tags in the model post. The same goes for the category, I don't know: p

Also, does limited context mean a particular model? So, for each limited context, would I have a different graph of objects (in the recording model)?

It takes some kind of brain wave to see it clearly in my mind; -)

To add a new message, my controller still requests the command bus for processing "ComposeCommand", the handler (PostService) creates a new instance of "Post", calls the layout method on it and, finally, asks for persistence to save the new publication.

The Post :: compose () method raises the event "PostComposedEvent", which the read model listens to update its data.

In all of this, I don’t know how to enter “Category” and “Tags”.

Thanks.

Answer 1

Only with these rules we already get a few limited contexts, am I right?

No, a blogging application usually covers only one limited context. It is when models have different meanings in different contexts that you need several BCs. This usually happens when the domain you are addressing becomes somewhat larger, consisting of several sub-domains .

However, you will have several aggregates - you can have several cumulative roots in one BC. The definition of aggregates in your domain model is based on several factors. First of all, the totality forms a boundary of coherence around an integral set of behavior associated with any root entity. For example, Post, most likely, AR, as well as Writer (Author). For an in-depth analysis of overall design, take a look at Effective Aggregate Design .

In all of this, I don’t know how to enter “Category” and “Tags”.

Typically, the message category and tag set are set as part of the command that creates your post-ComposeCommand in your case. Depending on whether you model the category and tag as aggregates or value objects, the command will either indicate CategoryId and TagIds, or simply values.