Domain Driven Design: making a domain modeling

Recently, I started to read Eric Evans's Book, Domain Driven Design, and I make a decision to share my learning journey as a little journal.

So I started with the first chapter from this book, an now, the first thing to do is to learn the domain where we gonna solve the problems. Let's make an exercise with this:

Develop a domain model for a hypothetical small business, such as a local bakery.

The first anectodes and lessons from this book is regarding with talk with the experts from the field, to gather some knowledge about what is the problem we're trying to solve, what are the pain they are feeling, and how is the best way to solve it.

The code now is just a side effect of a solution, but the way we draw the steps and define some concepts make the communication more direct and clear between development and business. The main mote for DDD is using domain concepts and an ubiquitious language. We should match our code and architecture with all the way of thinking of field experts.

Let's start the exercise by defining our domain. Bakeries generally are small businesses, and the main problem they have are regarding management. We can tackle here sales, people or stock management. So, we have a domain: Bakery Management.

We need to define a Bounded Context. We have some contexts where we can start to solve problems: inventory, people, sales, orders, recipes and others. Maybe we should do something for Inventory, a system for inventory and stock management. I think that's alright!

So, the next step is to start to talk to field expert to crunch some knowledge. By this time, I simulated this talk with AI!!
What I focused while talking with AI is to perceive the pain points in inventory management and focused more in the fabrication and quality inspection process of a bakery instead of the overall inventory and stock management. By the way, the result is the following picture:

So, we have the main Stock here, and some process in fabrication that produces and consumes products, like:

• The ingredient selection process;
• The quality control process;
• The every day inspection needed to make to see if some product is outside the due date;
• Wastes that are produced in the fabrication process.

In this step, you can learn somethings very valuable in the field, by expanding the base knowledge from the system description and make some drawing to take the general idea, making communication clear.

By the time, starting from here, we can start to draw some class diagrams and make some MVPs to cope with this process in the start and identify improving points. In the next posts, I will continue reading the book and provide more examples.