@swlaschin

Written in the persistence chapter under the section “Writing to a relational database”, that “we convert our domain object to a DTO and then execute an insert or update command.” I have a few questions on this.

1.) This doesn’t really seem to handle deletes. How would you recommend handle a command which deletes the root aggregate (and presumably all of its “children”)? Would the DTO just end up being a “null” which the persistence mechanism takes to mean “delete it all”?

2.) More troublesome, how would the aggregate root not be deleted but a child be deleted (e.g., removing an order line from an order).

Would we need to “mark” the line as deleted in our aggregate in order to know during persistence that it should be deleted? That seems like it would complicate the model for reasons of persistence.

Or perhaps our persistence logic deletes all order lines in the DB with IDs that are not in the order line DTO array?

Or maybe we retrieve the current state of the database as a DTO, do a diff with the DTO created as a result of our command

3.) In both of these questions (and specifically the second), there is the problem of concurrent transactions affecting the same aggregate. Are we essentially forced to use serializable transactions or record locking if we want to ensure that two transactions are not stepping on each others toes? Or is there another strategy here (besides strategies like event sourcing).

Thanks