Domain description
This describes the domain of the Pitstop application.
Event-storming is a workshop technique introduced by Alberto Brandolini that will help you to make sense of complex domains and (amongst other things) design event-driven software for such a domain. Although the Pitstop domain is not hat complex, I did use event-storming to analyse it. I have captured the result using Miro, a digital white-boarding tool (https://miro.com):
(Ctrl-click the image to open a full-size version in a separate tab)
In a real-world project, an event-storming session should obviously be a collaboration between the development team and business domain-experts.
Using the result of the event-storming session, I've created a context-map that describes the bounded contexts (DDD term) within the system and the relationships between them:
(Ctrl-click the image to open a full-size version in a separate tab)
The application uses the following domain-objects:
| Name | Description |
|---|---|
| Vehicle | Represents a vehicle. |
| Customer | Represents a customer that owns one or more vehicles. |
| WorkshopPlanning | Represents the planning for the workshop during a single day. A planning contains 0 or more maintenance jobs. |
| MaintenanceJob | Represents a job to be executed on a single vehicle. |
| Product | Represents a product (or part) that is used when executing a maintenance job or sold directly to a customer. |
| Sale | Represents a direct sale of a product to a customer (not related to a maintenance job). |
| Notification | Represents a notification sent to a customer as a reminder for a maintenance job. |
| Invoice | Represents an invoice sent to a customer for 1 or more finished maintenance-jobs. |
If you look at the context-map, you can figure out that Workshop Management is the primary bounded-context. This is where Pitstop Garage makes its money. That's why I chose to use a DDD approach (with Aggregates) and event-sourcing for this one. Customer Management and Vehicle Management are supporting bounded-contexts for which I've used a standard CRUD approach.
I've decided to leave support for Inventory Management (Products) and Sales out of the sample because this doesn't add enough value. As stated, the primary goal of this sample is to demonstrate different architectural concepts and not to be a full fledged application.
With every relationship I've specified which side of the relationship is Upstream (U) and which side is Downstream (D). Using these indications you can figure out which bounded-context in the system is the system of record (source of truth) for a certain piece of information. We call that side the upstream side. This side dictates the schema of the data and always holds the latest version of the data (the "truth"). The downstream side has to follow and use some approach to make sure it can use (and optionally cache) the data from the upstream system.
So for instance: vehicles are registered and maintained in the Vehicle Management bounded-context. But within the Workshop Management bounded-context, we need to have some vehicle information to be able to operate - even when the Vehicle service is offline (autonomy is very important in a Microservices architecture). So Vehicle information is cached within the Workshop Management bounded-context. This cache is kept up-to-date by handling events that are being published by the Vehicle Management bounded-context.