Identifying bounded contexts for meal planning app

Question

I'm designing meal planner app. I want it to has:

• typical cookbook with recipes (recipe can be added to cookbook by user, it contains list of ingredients with thier amounts, servings amount, calories amount calculated based on ingredients, ingredients can be added to shopping list and recipe itself can be added to meal plan). Recipes can be searched by some filters like cuisine type etc.
• meal planner - modifiable list of recipes for every weekday
• ingredients catalog - ingredients can be searched by filters, every ingredient some values e.g. calories. Perhaps it would has calculator for measurement (something like how many grams is in spoon of flour)
• shopping list - list of ingredients added from recipes or manuanly by user, they can be removed and their quantity can be modified

As for architecture I want it to be microservices based app. I have read some books like Building microservices, Domain-driven-design quickly and bunch of articles and tutorials. However I can't figure out how to slice domain to identify bounded contexts which would be microservices. All what came to my mind is division like I pointed cookbook, planner, ingredient catalog, shopping list but I'm not sure if it's good start for models designing in my app. I'm newbie and I would like to have some advices or ideas from someone who is into designing such things.

Answer 1

I'm designing meal planner app. As for architecture I want it to be microservices based app.

Services tend to be focused on do-ing rather than be-ing. Publishing a cookbook is one workflow, meal planning is another workflow, and so on.

An important idea in services is that they should be autonomous. There are a number of different ways to understand autonomy, but the one I find helpful is to consider that we copy data from producers to consumers so that the consumers can continue to do useful work even when the producer is unavailable.

For your example, meal planning needs a copy of a published cookbook. But it doesn't necessarily need today's cookbook -- a copy of yesterday's cookbook could be fine. We could achieve this if we had some asynchronous messaging that carries copies of the information from one service to another.

However I can't figure out how to slice domain to identify bounded contexts which would be microservices.

Right - that the hard part, especially when you don't have enough experience in the domain to know what the different processes are, which live data they share, which stale data they share, and so on.

The good news is that if you don't already know the answers to that, it's probably because the volume of information you need to handle right now is small enough that you can do it all together. In other words, first focus on deploying your domain model in a monolith, and iterate on the boundaries of the autonomous modules within it - paying special attention to which processes need to share live copies of the same data, and which processes can use stale copies of data.

Design your persistence model so that features never need to look in somebody else's table (information is copied, not shared). Make sure that the communication between modules satisfies location transparency, so that moving a component somewhere else doesn't break the world.