Thanks, means a lot! Yes, I had a chance, and I’m quite satisfied with the results — there are no many cases in which I can’t take advantage of the approach (at least not in HTTP server world). But like any other approach, this is not suitable for every use-case. The most important thing for me was to realize that each aspect/decorator should be applied conditionally. Besides that, I think it’s quite important for decorators to “delegate” work to the other more specific abstractions (e.g. ICache, ITransactionFactory, IValidator<T>). With these two things in place, there is a possibility to avoid using pipeline if a particular use-case simply isn’t suitable for it, and create a technically standalone handler which will handle the request using those more specific abstractions directly.

To give you an example, due to legacy reasons there is a need to split a single transaction, into two separate commits. It’s not possible to do it using pipeline’s transaction decorator (e.g. RequestHandlerTransactionDecorator) since it encloses the inner handler into a transaction. So, to circumvent the situation, such command shouldn’t be flagged to be handled by the decorator. In addition, ITransactionFactory should be directly injected into a command handler to “manually” implement what is required.