Currently, we have multiple commands which share two same properties (BookName and ShopId). While handling those commands those properties must be validated with the help of some service. Let's say that those validating process is just a two lines of code. Like this:
// Get book by name var book = await _booksRepository.GetBookByName(command.BookName); // Check whether that store contains that book _bookValidator.ThrowIfBookIsNotStockInStore(command.StoreId, book.Stores);
And then, inside all command handlers we are using that
We don't want to live with that two lines of code duplication across all command handlers.
So, one guy in our team offered to create some
BaseCommand which has
PopulatedBook property. And to register let's say
PopulateBookCommandHandlerDecorator for required command handlers. And that decorator will Execute that two lines of code and populate
Book property of the command.
And of course all required commands must be derived from that
In such way, we will convey getting and validating
Book object to the decorator and duplication will go to the hell.
But, I think that such design smells
fragility which is one of the symptoms which has to be avoided. I see two main problem here:
- We are modifying command object during handling with the help of decorator. I think it has to be "%immutable%".
- Decorator must be used only for cross-cutting concerns. And Getting book object from repository and updating command object is a core concern.
What you guys do think?
My opinion is to live with that 2 lines of code duplication and if lines number will reach to 3 or 4 then we can introduce some injection like
IBookPreparer which will validate book object and return.