Context map workshop management precision about pitstop HOT 5 CLOSED

Hi @NicolasReyDotNet

Thanks for your interest in Pitstop and I'm glad to hear you like it. let me try to answer your questions.

Question1
I've created the context map in PowerPoint. The italic items are items that are actually created and maintained in a different bounded context (BC). If you look at the WorkshopManagement BC for instance, I indicated that I need customer and vehicle data in order to operate. This data is stored in read-models in the WorkshopManagement BC (see also my answer on question 3). These correspond with the green read-model stickies in the Event Storm result.

Question 2
In DDD an aggregate can contain multiple classes. The aggregate root is the single point of entry to this aggregate and also maintains consistency of the entire aggregate. Within the WorkshopManagement BC, there is 1 aggregate: the WorkshopPlanning (aggregate-root) that holds multiple MaintenanceJobs (entity). In the code,MaintenanceJob is indeed not an entity, and that is actually a bug. So thanks for that! I recently added Aggregaroot, Entity and ValueObject base-classes to the WorkshopManagement domain. But I forgot to make MaintenanceJob an entity. I'll fix this a.s.a.p. (it's a small change).

Question 3
The Customer read-model in the Event Storm result, has not been translated in an actual Customer read-model in the Vehicle BC. This is handled by the front-end. The front-end will fill a list of available customers (to be shown on the Register Vehicle screen) by calling the CustomerManagementAPI directly:

[HttpGet]
public async Task<IActionResult> New()
{
	return await _resiliencyHelper.ExecuteResilient(async () =>
	{
		// get customerlist
		var customers = await _customerManagementAPI.GetCustomers();

		var model = new VehicleManagementNewViewModel
		{
			Vehicle = new Vehicle(),
			Customers = customers.Select(c => new SelectListItem { Value = c.CustomerId, Text = c.Name })
		};
		return View(model);
	}, View("Offline", new VehicleManagementOfflineViewModel()));
}

This is a conscious decision I made which results in a run-time dependency between the front-end and the CustomerManagementAPI and VehicleManagementAPI. (hence: I cannot register a vehicle when the CustomerManagementAPI is offline). Because the WorkshopManagement BC is most important, I've decided to make this service entirely run-time decoupled from the other APIs. So that is why within the WorkshopManagement, Invoicing and Notifications BCs, there are read-models (the items in italic font).

FYI: the read-models in each BC are updated by ingesting events that are published by the source BC. So for instance: when a customer is registered in the CustomerManagement BC, a CustomerRegistered event is published. This event is consumed by the other BCs and with the information in the event, the read-models are updated.

I hope I was able too answer your questions. Please note that most of this is also described on the Wiki. But if you read it and think the Wiki needs more information, please let me know so I can update it.

Greetings,
Edwin

from pitstop.

Update: I've just fixed the bug and pushed the commit (1a0227d). So MaintenanceJob now derives from the Entity base-class.

from pitstop.

Hi @EdwinVW

this is a pleasure to see that you keep connected to your repo and answer questions, I really appreciate!

1. I fully understand the role of the "data duplication" in the goal of making microservices fully autonomous. In fact I was a bit confused about the term, indeed I recently read the book from Alexey Zimarev (Hands-On Domain-Driven Design with .NET Core) and it's Github repo and what Alexey says about Read Model in Event storming context
   see link here.

The read model is something that our users look at before asking the system to do something. It could be any screen in our application, such as a form, a dashboard, or a report.

So I can't figure out if it's the same thing : a piece of data of any microservice A that microservice B needs to process a command, and thus which it stores in it's own context to be autonomous (what you say), OR any screen/view that lead the user to ask for a command.
What do you think ?

2. That sounds great, so in the Event storming schema, should MaintenanceJob be removed from Aggregate (yellow stick) ? In general, entity or value objects never appear on event storming schema ? (let says Aggregate Order with entity OrderLines , should Order the only stick to be shown ?)

3. Ok I understand, in the event storming, the customer read model what expected in vehicule, but to avoid "data duplication" process, you used a kind of aggregator pattern (to the customer BC) direclty from the presentation layer, isn't it ?

Thank you very much for your time, I try to learn as best as I can what DDD is and how to implement it, and any sample and discussion is a lot for me.
Your wiki is well documented, don't worry, maybe I read it too fast.

Best regards

from pitstop.

Hi @NicolasReyDotNet

1. Basically I agree with Alexey. For the WorkshopManagement BC, the read model is primarily to query and show data from the Customer and Vehicle BCs on the screen for creating a MaintenanceJob. This data is also shared trough a separate API (RefDataController). But the selected Vehicle and Customer info is passed in the PlanMaintenanceJob command. So Command Handlers should never need to access the read-model in order to be handled. This is the separation between read- and write. For the Invoice and Notification services though, the shared data is used in handling the events. Here we don't actually speak of a read-model because these services are not modeled after the CQRS pattern. For these services there is just one datamodel that stores data shared through events from other services (read-only cache). I hope this clarifies it for you.

2. In the event storming session, I usually focus on business entities (not the DDD term, but the general term). You don't think about aggregate roots, DDD entities or value objects. But I do want to have the entities as stickies on the wall for discussion purposes. When I start modelling the domain for implementation, I decide on 1 or more aggregates, aggregate-roots, entities and value-objects (this is less important for the business stakeholders).

3. Check :)

Greetings,
Edwin

from pitstop.

Hi @EdwinVW

Many thanks for your time, it helps me a lot, I'll continue to spend time in learning DDD and Event storming, maybee I may encounter new points that I could talk with you ?

Have a good day, and thanks for your work

from pitstop.