I really liked his talk and admit that he made me think critically on our current architecture approaches. This was by far the best architecture talk on TechED 2009. There were so many interesting ideas and concepts. This article sums them up.
Current n-tier Architecture Weaknesses
Software development is all about helping customers to solve problems and/or do some work. It only serves for something if there are added values and if the user intents were correctly discovered and satisfied. Udi stated that the current n-tier approach may not always provide the best way to achieve this goal.Developers spend most of their time on building software infrastructures instead of concentrating on solving user needs. By having all these different layers in a n-tier architecture there is also the need for transforming data between them. This transformation makes maintainability and extensibility much more complicated.
Much overhead is added for data transformations. Functionalities that the user will not see in the end and that will cost performance (nothing is for free). No added value! The user is just interested in the final result – the application that he uses to achieve his goals.
If the application is not doing what the user needs than he will not be happy with it, even if the underlying architecture was from a technical point of view “perfectly” designed.
That is why we need to break free from our current thinking and try to approach problems in another manner. Ideally the goal of software architecture is to come up with simple solutions for complex problems.
Udi presented a more simple way of displaying read only data in the UI (which is a use case that does not apply to all user needs but sometimes it is just what needs to be done). Let the UI have a direct connection to the “Persitent View Model” (in other words have a view in the DB for each view in the UI).
By doing it like this all intermediary steps are suppressed and when there is a change only the UI Layer and the corresponding views are affected. Simpler, easier to maintain and providing better performance! A win on each level!
This is not possible for all application scenarios but if possible it should be considered when designing application architectures.
Validation and Business Rules
The next topic concerned the separation of Validation and Business Rules: What is covered by Validation and what needs to be done in Business Rules? Udi provided a good explication, that says that Validation should be done upfront to assure that the input is correct (and only that). Business Rules apply to a combination of system states and business logic. They decide if the treatment must be continued or aborted.
Command Processing Layer Approach
If we consider a new layer approach that handles commands we could describe the different layers and their interaction as follows.
Capturing User Intent
Udi gave an example of how to capture user intents and how to architecture the system that fulfills the user needs. He took an example of a ticket reservation system for a football stadium and how the IT system was built to satisfy the users.
The user enters his needs into the system and gives information of what is acceptable (ex: 4 places together in a group, seat type, etc…). The systems then searches asynchronously if the user needs can be satisfied and alerts the user via email when it has finished (it either finds the places and reserves them or it doesn’t). Less frustrations for the user since it is the system that finds the places and reserves them (in fact working like an agent).
Summary
By using the Command Query Responsibility Segregation Principle that he introduced and having an asynchronous approach the system is more scalable, easier to maintain – and for the user – easier to use and understand.
