In the application I am working on, the user can start an Order without Order Lines, but the order cannot be persisted without order lines and other properties where other aggregates are referenced (which in the database are foreign keys which do not accept null values, this is why). This order is kept in cache until the user confirms it, that is the moment to persist it.
I think creating an aggregate root via its constructor leaving it in an inconsistent state regarding its persistence should not be possible. Is there something wrong with my thinking? because if this is possible, how do I handle the rules for its persistence? In the application service? In your repository? via a function (maybe "IsValidToPersist") in the aggregate root?
I see sense in the fact that the Order can be created without all the properties it needs for its persistence, in this case. I usually check for these needs in the aggregate root's constructors, throwing exceptions if the aggregate root is not ready to persist, among other business rules. I guess if this can be so, then there must be application services like "CreateOrderService", "AddOrderLineService", and "SaveOrderService" / "AddOrderService" where it would persist. And not just an "AddOrderService" service where it is created and persisted at the same time.
To update an Order Line, should I create an "UpdateOrderLineService" service that will find the Order, update its order line through its functions? Or should it be all that it takes to update an Oder in a single service "UpdateOrderService"?. I think this second option complicates some things. For example, it is difficult for the service to know which order lines to add, update and delete. Although that could be solved with a function in Order like "ChangeOrderLines" and simply replace them. In the first option, should the Order be persisted with each update (or even addition or deletion) of order lines? I can think of other options such as: return the updated Order or return the updated (or added) Order Lines (although this is not such a good idea).
My question, really is: is it convenient that exists services to handle the child entities of the aggregate root?
Aucun commentaire:
Enregistrer un commentaire