Question on Meanwhile on the command side of my architecture.

[FrankyCTY]

Hi Steve.

After looking into the article https://blogs.cuttingedge.it/steven/posts/2011/meanwhile-on-the-command-side-of-my-architecture/

I see that the way we have this interface "ICommandHandler" a seam into our application to make use of decorator pattern and it is a form of aspect-oriented programming (AOP).

Many application does not have this design, and the production code classes (not sure how to call them) usually have specific interface that define the behavior specification, such as ICustomerService for CustomerService e.g. which constraints the behavior by having the specifications of the methods in the interface contract.

By having this seam, we need something like ICommandHandlerDecorator which separate the data from the behavior specification.

That means the generic ICommandHandler interface only constraint the data used, but the behavior is not.

---

I am thinking in that case if I want to swap the dependency for e.g. testing, will it make it easier to have human error as we could pass in the wrong implementation when complying to the data constraint?

Although in the test use case, it is something we will spot the human error immediately when we run the test, also each command handler effectively only has 1 method.

Thanks.

[FrankyCTY]

My understanding after reading the command and query articles.

Lots of issues you mentioned in the query side of my architecture around the violations of SRP, OCP, ISP all comes down to cohesion, specifically caused by the informational cohesion. And what actually solves the problem is of course understanding the context, the business/product needs and the capabilities your applications need to offer, and design for a functional cohesion application that leads to good coupling (and less).

With the pattern you mentioned, we essentially switching from horizontal sliced to veritical sliced application architecture I supposed.

So the scope of this pattern is not like a simple class level pattern but an application architecture pattern as it could be a application wide changes especially we are dealing with cross cutting concern.

Since the consumers code will need to couple (connect) with this new interface which can be a seam for decorator class that encapsulate the cross cutting concern behaviors.

---

By the way, I am enjoying your amazing dependency injection principles, practices, and patterns book, thanks a lot!