How to perform checks before deleting an entity?

[Newm]

I have started experimenting with CQRS/ES and have created a very basic project, the idea is that I need to record details of model cars such as Matchbox, Corgi, Dinky, etc.

I have broken it down into 3 aggrigate roots:

Manufacturer (Matchbox, Corgi, Dinky)

Series (Matchbox->Hot Wheels, Matchbox->75s, etc)

Vehicles

A series must have a manufacturer, a vehicle must have a series.

I have created a number of commands and events to allow the creation of manufacturers and series e.g.

CreateManufacturer

CreateSeries

CreateVehicle

ManufacturerCreated

SeriesCreated

VehicleCreated

Before allowing the user to delete a manufacturer I would like to check that there are no series linked to it.  Similarly I would like to ensure that there are no vehicles linked to a series before allowing it to be deleted.

How should this be handled?  Should I create a service which uses the read models to determine if a manufactuer/series is in use before sending a DeleteManufactuer/DeleteSeries command or should the manufacturer/series domain objects (aggrigate roots) internally track the number of items linked to it using the Apply override (i'm using CQRSLite)?

If I go down the domain object path should the CreateSeries command be replaced with a AddSeries method on the manufacturer domain object?

[Constantin Galbenu]

It depends on your business needs in this particular case: if you need strong consistency then you must do the verification inside a bigger aggregate but if you can accept eventual consitency then you should use a read model.

[Newm]

Using my example would the larger aggregate have be made up of lists of manufacturers, series and vehicles with methods such as AddManufacturer, AddSeriesToManufacturer, AddVehicleToSeries?

The aggregate could then keep internal counts of number of series per manufacturer and number of vehicles per series.

If this is true wouldn't I end up with one God object that has to replay all of the events since the beginning of time (or since the last snapshot) to arrive at the true state?  For example if I wanted to know if I could delete a series I would have to build the aggregate by replaying all the events of every vehicle that was ever created/deleted to determine the number of item currently in the series?

Sorry if i'm over complicating this, just trying to get my head around the ES way of thinking.

[xprt64]

Indeed, the stronger the consistency is the greater the aggregate becomes. That's why you need to give a very high priority to your business requirements. 

So, you should try to implement the "serie deleting" as a process that do the checking in an eventually consistent manner (for example using a readmodel ir storing a private state with all creared cars) and then perform the actual "deleting". I used quotes because there is no actual deleting of entities in event sourcing, "delete" must have a meaning in your ubiquitous language.

If you may not use eventual consistency then you really need an aggregate instead if two or three. 

An example of how eventual consistency may manifest itself: the model deleting process mangers do the checking, the check passes  (there are no cars of that model) but before the DeleteModelCommand is executed another Car of that model is added and that Car would become orphan - its model would not exist anymore (it would not be present in readmodels). If this is improbable to happen or the impact is low or you can detect and repair then go ahead with a process manager.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

From my experience, ES tends to be most valuable for multi-step logic and less valuable for lists of data with set constraints. I have event-sourced CRUD data, but it ultimately requires consistent helper write models to enforce set constraints like uniqueness.

ES could be more interesting if you were tracking, for example, progress on building model cars. Most of the events would have the IDs of entities like ModelInfo or the User but not the data itself. With those events, you could easily generate views (tables) to answer questions like "who is building this model?" "how long has this model taken my users to build?" "which are the most popular among my users?" etc. The model data itself could be stored in standard SQL tables. If you want an audit history of the CRUD data, temporal tables can do that for you.

IOW, lists of data are not a great starting point for ES.