Command and Query Handler decorators are numbered as 0.5 in the heirarchy. You may have noticed something slightly odd about the numbering system. (Do note that objects do not know they are referencing decorated instances.) for Query Strategy and Command Strategy Handlers.We can expand this further to show the allowable dependencies with cross-cutting concerns (decorators) The examples can be arranged into a logical heirarchy which can be visualised as: 1. Public interface IDataQueryHandler where TQuery : IDataQueryĪbstractions such as the examples shown above allow us to easily separate logic that is the whole from logic that is the part. Public interface IQueryStrategyHandler where TQuery : IQuery Public interface IDataCommandHandler where TCommand : IDataCommandĪctions that return something and change nothing Public interface ICommandStrategyHandler where TCommand : ICommand Lower level abstractions that are part a of something (you could almost consider these abstractions to be strategies).Īctions that change something and return nothing.A holistic abstraction, an abstraction that acts as the whole of each transaction.To resolve this dilemma We need multiple layers of abstractions. Some are concerned with the transaction, others are only concerned with a small piece of a transaction. Not all cross-cutting concerns are equal. But it is this same feature that can get us into so much trouble.
(And possibly even called commands from within other commands.) Commands and Queries are cool the way many of us have been using them all this times so why would we need this control, this limitation, on Queries when we’ve been using them in Commands for ever?įor one thing, Commands and Queries are cool because they offer a simple, consistent and convenient way to apply cross-cutting concerns. There are many of us, myself included, that have always used queries within commands, and queries within queries. A Command should never reference a Query. The reporting database may not yet be in sync with the domain.Ī Query should never reference a Command. Querying the current state of the domain should not be confused with reading data from the database. Queries are a stale view of data they are a view of the domain at a point in time. To bring a holistic view to queries we need to see them as a whole thing: It’s easy enough to see a Command as a holistic abstraction, but less so a Query. This simple definition makes Commands and Queries the same thing. Holistic Abstractions are concerned with the whole transaction they are not a part of a transaction. My solution to this problem involves a single golden rule.Ĭommands and Queries are Holistic Abstractions. Our favourite abstractions are in danger of becoming abstractions that do too much!
Public interface IQueryHandler where TQuery : IQuery Queries report on the current state of the domain Public interface ICommandHandler where TCommand : ICommand In other words, asking a question should not change the answer.Ĭommands initiate state change by executing the appropriate behaviour on the domain Bertrand Meyer defines CQS as: every method should either be a command that performs an action, or a query that returns data to the caller, but not both. If you are unfamiliar with these two patterns then please see these posts here and here for a great introduction. In this post I will outline an updated perspective on Commands and Queries with respect to applying cross-cutting concerns (aka Aspects or Decorators).
0 kommentar(er)
