Ideal architecture
There are many different views on the development of architecture and design of modern applications. Some architects seek to think through every detail, paint the use cases of all classes and modules, analyze a million possible ways to use them, document them all, and then proceed to the coding stage.
Others, on the contrary, believe that it is “too late to think” and it’s time to “do it” long ago, so they rush to the barricades with shouts of “Hurray”, giving tons of unnecessary code to the mountain. Like any extreme, such an approach does not lead to anything good. But, as in many other cases, there is an intermediate option when due attention is paid to design and architecture, when they are not placed at the center, but used to identify the right abstractions and search for compromises in the conflicting requirements of the customer.
')
When it comes to class design, module architecture, or the responsibility of different layers of an application, the concepts of cohesion and coupling will play a decisive role in their design. Even Christopher Alexander, the “father” of design patterns, wrote that the main task in decomposing a system is the fulfillment of two conditions: (1) maximizing connections within components ( high internal coupling , tight internal cohesion) and (2) minimizing connections between components ( loose external coupling, loose external coupling).
NOTE
More information about the history of the emergence of such a unique concept as design patterns (design patterns) can be found in the article: Design patterns. Success story .
Thanks to Bob Martin and some other well-known personalities, principles appeared in our arsenal, such as SOLID, which make it possible to determine more precisely (or, perhaps, more formally) whether the system design meets the above principles or not. I usually, before moving on to "heavy artillery", in the form of such principles I use a simpler approach. I ask myself the following question: “But how realistic is it to cover the main functionality of this class with modular tests?” If the answer is positive, then surely this class has a sufficiently high cohesion and low coherence with other classes. If even a purely theoretical writing of a unit test is impossible, since the responsibility of the class is not clear, it contains a bunch of fields and methods unrelated to each other, and depends on two dozen other entities, then there is clearly something wrong with the design.
Figure 1 - And how to test this miracle? But in real life there can be several times more connections
TIP
Use the class “testability” principle as a “litmus test” of a good class design. Even if you do not write a single line of test code (although in vain!), The answer to this question in 90% of cases will help you understand how “good” or “bad” everything is with its design.
When it comes to the architecture of an application or module, “testability” cannot be a quality criterion. Of course, we can create integration tests for entire subsystems, but they will most likely provide very little useful information about the adequacy of their architecture.
When deciding architectural issues, such as choosing a platform for building distributed applications, choosing a UI framework or data access layer architecture, it is reasonable to ask yourself another question: “What if the decision made now is wrong?” Or “In general, should I make the final decision right now? "
Abstraction and encapsulation are still our best friends and that’s how they are perfectly applicable to individual classes as well as whole modules or application layers. Using WCF should be maximally hidden in the communication layer, the UI framework should not stick out of all base classes, and the data access layer architecture should not impose restrictions on the business classes of the application. Of course, according to the “ law of leaky abstractions, ” occasionally unnecessary details will still be sneaking into other layers of the application, but we should at least try to limit them.
Good architecture should not be thought out in detail; A good architecture must be thought out well enough to understand how much architectural errors in one part of an application will break down at all other logically unrelated modules.
TIP
If the "litmus test" of the quality of design classes was their testability, then the litmus test of the quality of architecture can be considered its "flexibility." Ask yourself: “What will happen if the current architectural solution turns out to be wrong?”, “How many modules will undergo changes?”. Whenever possible, architectural solutions should not be “cut down in stone”, and the consequences of architectural errors should be reasonably limited.
Quite a lot has been written about the importance of a pragmatic view of architecture. Grady Booch in her famous book repeatedly stops on the importance of abstraction and encapsulation at various levels. In the remarkable book “97 etudes for software system architects,” many authors often talk about the dangers of “cutting solutions in stone” and the advantages of simplicity over flexibility in architecture.
One of the last famous authors, the subject of architecture was raised by Bob Martin. In one of his presentations, as well as in one of his posts about architecture, Bob wrote the following: ... Good architecture allows you to DELAY key decisions ... Good architecture maximizes the number of NOT-MAKED decisions .
Of course, I do not 100% agree with the old Bob that all architectural solutions can be postponed, but I agree that good architecture allows us to postpone many of them. And here even the matter is not only and not so much in the time of making these decisions, but in the cost of their subsequent corrections.
NOTE
The presentation of Bob Martin, which I mentioned above, can be found here , a short video, with a discussion of this issue, here . And here are a few Bob posts on the same topic: Clean Architecture and Screaming Architecture .
I strongly advise readers not to take the above principles as a “silver bullet”, which is guaranteed to give you an answer to the question of how to get the “perfect design” or “perfect architecture”. Such questions can only show gaps, but cannot show the right path, they can only ignite an alarming light in your head and encourage you to more thoroughly analyze the design of a class or architectural decisions.
Others, on the contrary, believe that it is “too late to think” and it’s time to “do it” long ago, so they rush to the barricades with shouts of “Hurray”, giving tons of unnecessary code to the mountain. Like any extreme, such an approach does not lead to anything good. But, as in many other cases, there is an intermediate option when due attention is paid to design and architecture, when they are not placed at the center, but used to identify the right abstractions and search for compromises in the conflicting requirements of the customer.
')
When it comes to class design, module architecture, or the responsibility of different layers of an application, the concepts of cohesion and coupling will play a decisive role in their design. Even Christopher Alexander, the “father” of design patterns, wrote that the main task in decomposing a system is the fulfillment of two conditions: (1) maximizing connections within components ( high internal coupling , tight internal cohesion) and (2) minimizing connections between components ( loose external coupling, loose external coupling).
NOTE
More information about the history of the emergence of such a unique concept as design patterns (design patterns) can be found in the article: Design patterns. Success story .
Thanks to Bob Martin and some other well-known personalities, principles appeared in our arsenal, such as SOLID, which make it possible to determine more precisely (or, perhaps, more formally) whether the system design meets the above principles or not. I usually, before moving on to "heavy artillery", in the form of such principles I use a simpler approach. I ask myself the following question: “But how realistic is it to cover the main functionality of this class with modular tests?” If the answer is positive, then surely this class has a sufficiently high cohesion and low coherence with other classes. If even a purely theoretical writing of a unit test is impossible, since the responsibility of the class is not clear, it contains a bunch of fields and methods unrelated to each other, and depends on two dozen other entities, then there is clearly something wrong with the design.
Figure 1 - And how to test this miracle? But in real life there can be several times more connections
TIP
Use the class “testability” principle as a “litmus test” of a good class design. Even if you do not write a single line of test code (although in vain!), The answer to this question in 90% of cases will help you understand how “good” or “bad” everything is with its design.
When it comes to the architecture of an application or module, “testability” cannot be a quality criterion. Of course, we can create integration tests for entire subsystems, but they will most likely provide very little useful information about the adequacy of their architecture.
When deciding architectural issues, such as choosing a platform for building distributed applications, choosing a UI framework or data access layer architecture, it is reasonable to ask yourself another question: “What if the decision made now is wrong?” Or “In general, should I make the final decision right now? "
Abstraction and encapsulation are still our best friends and that’s how they are perfectly applicable to individual classes as well as whole modules or application layers. Using WCF should be maximally hidden in the communication layer, the UI framework should not stick out of all base classes, and the data access layer architecture should not impose restrictions on the business classes of the application. Of course, according to the “ law of leaky abstractions, ” occasionally unnecessary details will still be sneaking into other layers of the application, but we should at least try to limit them.
Good architecture should not be thought out in detail; A good architecture must be thought out well enough to understand how much architectural errors in one part of an application will break down at all other logically unrelated modules.
TIP
If the "litmus test" of the quality of design classes was their testability, then the litmus test of the quality of architecture can be considered its "flexibility." Ask yourself: “What will happen if the current architectural solution turns out to be wrong?”, “How many modules will undergo changes?”. Whenever possible, architectural solutions should not be “cut down in stone”, and the consequences of architectural errors should be reasonably limited.
Retreat from the topic. Clean Architecture by Bob Martin
Quite a lot has been written about the importance of a pragmatic view of architecture. Grady Booch in her famous book repeatedly stops on the importance of abstraction and encapsulation at various levels. In the remarkable book “97 etudes for software system architects,” many authors often talk about the dangers of “cutting solutions in stone” and the advantages of simplicity over flexibility in architecture.
One of the last famous authors, the subject of architecture was raised by Bob Martin. In one of his presentations, as well as in one of his posts about architecture, Bob wrote the following: ... Good architecture allows you to DELAY key decisions ... Good architecture maximizes the number of NOT-MAKED decisions .
Of course, I do not 100% agree with the old Bob that all architectural solutions can be postponed, but I agree that good architecture allows us to postpone many of them. And here even the matter is not only and not so much in the time of making these decisions, but in the cost of their subsequent corrections.
NOTE
The presentation of Bob Martin, which I mentioned above, can be found here , a short video, with a discussion of this issue, here . And here are a few Bob posts on the same topic: Clean Architecture and Screaming Architecture .
Conclusion
I strongly advise readers not to take the above principles as a “silver bullet”, which is guaranteed to give you an answer to the question of how to get the “perfect design” or “perfect architecture”. Such questions can only show gaps, but cannot show the right path, they can only ignite an alarming light in your head and encourage you to more thoroughly analyze the design of a class or architectural decisions.
Source: https://habr.com/ru/post/133287/
All Articles