I'm designing meal planner app. I want it to has:
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.
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.