Linear design approach

Peasy was designed to free ourselves from complications we often face in domain-driven designs, and favors a more linear approach to design and development.

It is recommended that DTOs map directly to a data store entity (database table, document, etc.). While a DTO can map across multiple data store entities, it is encouraged to keep a 1-1 mapping between DTO and data store entity.

Keeping 1-1 mappings between DTOs and data store entities greatly simplifies insert, update, and delete logic in the peasy framework. This can be attributed to the fact that during one of these operations, you don't have to inspect a DTO for the existence of children (the case for inserts and deletes) or the existence of dirty children (the case for updates).

Let's take a in-depth look at this example. Say your data base contains tables to represent customers, orders, and order items. Now let's suppose that you have a Customer DTO that exposes a list of Order DTOs, and each Order DTO has a list of OrderItem DTOS.

Here's a code sample:

Now let's suppose you have created a customer service, exposing an UpdateCommand method that accepts an instance of CustomerDTO as an argument. To update it, you are now responsible for looping through each OrderDTO in the Customer.Orders list, checking for new orders (which would call for an insert operation), checking to see that orders haven't been removed (which would call for a delete operation), or checking to see that data has changed (which would call for an update operation). This same logic then would have to be applied to OrderItem DTO instances stored in each Order DTO.

While you could just ignore children during an update operation against the customers service, you are still left with a customer DTO with dangling properties that have little to no context within an update operation, which smells

When you keep your DTOs linear, your intentions about its usage are always clear.

So how do we get around this design issue with peasy?

Mention something about CQRS being an exception to this rule.

Handling parent / child scenarios