I understand from Udi’s course about Autonomous Components that they should be fairly granular in terms of the handlers they contain, preferably aligned to a single use case. I’m trying to determine if this means one handler only per AC or if there are exceptions to the rule.
Let’s say we have a use case for Sales service called ManageCartItems that implies adding and removing items from a cart. We’ll assume we don’t have Add and Remove as individual use cases as being able to add without remove would be less than functional to the business.
I see 3 possible development structures that could be used:
- One AC called Sales.ManageCartItems. Contains handlers for AddItemToCart and RemoveItemFromCart
- Two ACs, one called Sales.ManageCartItems.AddItemToCart and the other Sales.ManageCartItems.RemoveItemFromCart. Each contains only their respective single handler.
- Two ACs, one called Sales.AddItemToCart and the other Sales.RemoveItemFromCart. Each contains only their respective single handler.
I would think that adding and removing items from a cart would use the same functionality to achieve their goals. Same data structure too. So any requirements change for managing items likely would affect both handlers, or the code both consume.
With this in mind is no 1 an acceptable approach?
I guess I should also ask, is this style of naming ACs even correct? It seemed logical to have the use case name somewhere.