What to improve/change and how to move forward with my Event Storming session?

Question

I'm doing alone session with Event Storming for my application that I plan to build with DDD approach later on. Event Storming session is for learning purposes.

My application domain logic is rather simple one. The application is called - "Vehicle Maintenance Management System" (VMM System). Below there are some general rule and logic of the application:

• User can register, sign in, reset his password and update some basic information about the account, so some really basic user management logic.
• User can add/remove/update his car data (so typical CRUD operations here).
• The main goal of the application is that user can replace some car's parts to have a valid information about the car parts that are used in the vechicle. The system can notify about some part replacement deadlines based on the car's mileage or date.

So I did an Event Storming session contained Big Picture and Level Processing steps. The result of my session is on the below screenshot:

Here is a legend for my colours:

My question is am I doing that in a right way? Do you see any things that can be improved in my session? What should I do next?

I've found four aggregates:

• User
• Cars management
• Parts management
• Notification

In my opinion there should be exposed two aggregate roots:

• User
• Can management (which uses Parts Management aggregate to operate on car's parts. User should not be able to access Parts Management aggregate directly)

Am I thinking in a correct way here? I would like to understand that as much as possible - any tips are really appreciated :)

Answer 1

Biggest constructive criticism I have is that you are still very much in a CRUD mindset rather than an Event Sourced mindset. In general restrict the language you use to describe the concepts:

• Aggregate Roots: simple plural noun. I.e. use "Cars" instead of "Car Management" or "Users" instead of "User".
• Events: past tense verbs. I.e. "Car Inspected"
• Commands: present tense verbs. I.e. "Inspect Car"

Approach the problem with the domain terminology of your customer. Take the idea of a parts or inventory management feature. With this feature, parts are inventory that a garage has to have on hand in order to perform maintenance on cars. So they have an independent system. Whether you call it "Parts", "Stock", or "Inventory" depends on the domain terminology your customer uses.

Parts

• Command: Order Parts -> Event: Parts Ordered
• Command: Receive Order -> Event: Parts Received
• Command: Stock Part -> Event: Part Stocked
• Command: Check Inventory -> Event: Inventory Corrected
• Command: Pull Part -> Event: Part Pulled
• Command: Return Part -> Event: Part Returned (to manufacturer, i.e. defective)

In each of the cases above, we aren't talking about Create, Read, Update, Delete (CRUD) operations. Those are very database-centric concepts. We are talking about actions that the users need to perform when managing the parts. When we replay the domain events we should be able to come up with the same state.

Event Sourcing and Event Sending

The term "Event" is overloaded in our industry. Some teams have opted to use the word Facts instead of events to describe the things we store and replay to get to our current state. Another common word is Message to refer to active messages used to perform work asynchronously. Whatever your choice, it would be very useful for your team if you agreed on the terminology you use to describe Event Source events from notification events, etc.

Digging Deeper

Once you figure out the things that can happen, you'll need to figure out what information is needed in that event. You don't need everything, but every event should have a timestamp, a user to attribute the event to, and the actual information that is changed.