I got a very interesting observation regarding the last post from a person that I follow closely. His technical teachings help so many, that I guess if he comes with such an observation it must be one that a lot of people will.
The observation was that albeit both patterns are structurally comparable, the contexts where each are applied are so different in nature that similarities may be irrelevant.
As naive as it may sound here is why it may not be such case.
Although the term "structure" was used, the scope of this term is basically one of diagram structure. What may be more relevant is:
- The way each pattern distributes responsibility amongst the concepts is the same.
- The information flows amongst concepts in the same way.
In other words, the top level algorithm is the same.
If algorithms are the same, the probability of problems solved by each ending up being of the same kind is quite high. In the end of the day we are building software and few things can be more asynchronous and prone to errors then a person or group of persons interacting with the same UI.
Considering how different the play field of each pattern is, probably we are facing a singularity, a constant solution in systems design that solves a particular set of top level problems across a wide set of technical contexts. This whether the challenges is one of building an UI or a distributed system that needs to be highly scalable. This usually rises some opportunities of simplification across the board.
Within the Domain Controller take for instance the concept of Saga. The Saga pattern is a solution applicable when we identify multiple inputs that need to be treated together has a unit (all or nothing). Yet we cannot put all those inputs into a single transaction (think a complex client/server interaction with multiple calls). The Saga gives the client the illusion that is dealing with one single domain concept yet it is orchestrating several domain objects (enforcing invariants etc). We can imagine a very large Order built over time common in procurement processes. After the transaction ends, the Saga is disposed yet the Order remains.
A similar situation we have in the UI space when dealing with editing and presenting complex sets of information that need to be treated has a unit(say a complex task such as user registration or payment). The amount of information to be collected is such that to simplify, we split the information along several screens, each capturing only a part of the information (Wizard). This problem is solved with MVC by introducing the concept of Tool. A more sophisticated tool is one of Composite Tool hence we come to the reasoning around Composite UIs (BCs etc). When the Wizard is submitted all the data collected is sent to the domain model and the Tool is then disposed.
Quite often the subject of task based UIs come along with CQRS and scalability. Generally speaking my understanding is that by aligning the design of the UI with the way information flows across CQRS participants (and vice versa) we get a system that is far more scalable while keeping the implementation recurrent and simple then we could otherwise.
Currently I'm not at the level of decision making where were I can apply this. So to me this comparison may bring some light in explaining why such alignment may be so elegantly effective.
If everything above fails in explaining why it may be of relevance then at least it will not fail in bringing awareness on how similar both patterns are. As such we can only wonder if experiences (successes and failures) on building solutions and tools around MVC can be selectively transposed to the environments where CQRS is of value (avoiding the pitfalls of some approaches and capitalize on success of others).
Nenhum comentário:
Postar um comentário