Domain Method Duplication

I am currently working on a domain-based Eric Evans project book, and there is one concept that I'm having problems with ...

According to the book, all aggregates should have a common root, and all members of the aggregate should only get access through this root. The root must also be responsible for the forced use of invariants. Will this lead to a lot of duplication of methods? Take, for example, the following scenario:

I have an Order class that consists of an OrderLine set. Class Order is the aggregate root in this case, and it must provide an invariant so that all OrderLine of one order have a unique serial number. To ensure that this invariant is not violated, the Order class does not expand its OrderLine and simply offers the updateOrderLineOrderNumber (long orderLineId, int newOrderNumber) method through which OrderLines must be updated. This method simply checks to see if newOrderNumber is in conflict with an existing order number, and then calls the updateOrderNumber (int newOrderNumber) method of the corresponding OrderLine. This is great because it is only one method, but what happens when the OrderLine class has several methods? Since the order does not disclose its OrderLines, all OrderLines properties must be updated using the Order class, even if changes to the properties do not require any verification of the invariant. This will undoubtedly lead to a lot of duplication of methods, which will only worsen as more classes are added to the collection.

I get it wrong? Are there alternative mechanisms or design patterns that I could use to prevent this scenario?

One of the possible strategies that I was thinking about using is the concept of validators. Whenever the OrderLine property changes, it must first check with a set of validators whether this change is allowed. An order can then add the appropriate validator to the property of the OrderLine name whenever an OrderLine is added to the order. What do you guys think about this strategy?

Any help or thoughts would be greatly appreciated!

+6
source share
1 answer

I donโ€™t see a problem here, to be honest. First, why do you want to change orderId? The identifier must be set once, the other id is equal to a different object.

Usually, if you want to update an AR object, you just get it and update.

orderLine = order.getOrderLine(index) orderLine.changeProduct(someProduct) 

If you need to store some invariants in AR, for example, that OrderLine.product must be unique, you call the AR method.

 order.changeOrderLineProduct(orderLineIndex, someProduct) 

Internally, this method checks if someProduct is unique, and if it then calls the code above. There is no DRY violation in this, the AR method checks the invariants, updates the orderLine method.

I would also think about using more UL in this, for example, "The customer changes the product to his custom line to order"

 client.changeOrderLineProductOnOrder(orderLineIndex, product, order) 

This way you can check if the customer is the owner of this order.

+1
source

Source: https://habr.com/ru/post/972633/


All Articles