Separation of concerns

Question

I'm approaching the DDD way and I was posing myself some questions. Assume that I'm writing an application that lets you define a nutritional week, where you can

• Define a nutritional week as a resource having a list of aliment to eat for each of the 7 days
• Activate/deactivate the created weeks in a sort of calendar

My idea was to have two bounded contexts: the Nutrition and the Progress bounded contexts. The Nutrition BC is responsible of creating the nutritional weeks (similar as a portfolio), while the Progress bounded context is responsible of tracking the user nutrition.

Inside these two BC, I will have a NutritionWeek aggregate and in the Progress BC a PlanWeek aggregate. Now, I have some doubts on where the activate/deactivate functionalities should resides. I was thinking that these should be on the NutritionWeek aggregate: when the user activate a NutritionWeek it will call a domain service which will check if a NutritionWeek is already active, if yes -> exception, if not -> an event NutritionWeekActivated will be fired. In this event the NutritionWeek essential information is reported and the PlanWeek aggregate will handle this event by creating 7 PlanDays value objects, containing the aliments specified in the NutritionWeek. When a NutritionWeek is updated and is currently active, a NutritionWeekUpdated event is fired and the PlanWeek will handle the event by updating its PlanDays.

In general, I think that the PlanWeek should only be responsible of tracking the User nutrition. On the other hand, the NutritionWeek responsibility is to tell to the PlanWeek how to create its PlanDays.

P.S: at the moment I'm not planning to use events, so the integration between these two BC will be done as Open Host and Http/Rest. So, there would be an application service in the Nutrition BC that will activate the NutritionWeek and then call the Progress BC via HTTP.

What do you think?

Answer 1

According to Evans, a bounded context is :

The delimited applicability of a particular model. Bounding contexts gives team members a clear and shared understanding of what has to be consistent and what can develop independently.

So separated bounded contexts imply a clean separation of concerns. But conversely, does separation of concerns necessarily need to shape the bounded context? Not necessarily.

If your nutrition and planning candidate-contexts are very complex, and each has different subject matter experts, use some different terms or terms differently, and if the complexity is so big that different teams will be involved, then go for different bounded context.

But from your narrative, this does not seem the case. Don't artificially create bounded context, just to mirror the subdivision of your components. There is a slight risk of over-engineering here.

And fortunately, there are plenty of other means at our disposal for separating concerns, such as aggregates, services and even repositories (in their own way). Bounded context is realy the steamroler in this regard, which in addition requires some overhead for coordination. DDD is meant for helping you to get your domain right. Up to you to keep it as simple as possible ;-)