[1/2] Complexity and modularity are two sides of the same coin - Vlad Hononov - ArchDays 2023 (Category Architecture)

Interesting. speech Vlada Khononova from the conference on architecture, the program committee of which I am a member. In this talk, Vlad briefly described the relationship between complexity and modularity, which allows you to introduce interesting system and code quality metrics that simplify coupling/connascence/cohesion. This report is based on the book Balancing Coupling in Software Design, which I will order in paper immediately after its publication.

Let’s go through the main thoughts of the report. Vlad defines a system as a set of interconnected elements organized to achieve a goal. (It's based on the definition of Meadows from "The ABC of Systems Thinking," which I'm already talking about. told) Next, the author goes deep into the levels of abstractions and shows that the system is a fractal history of the species: the system is a system.> microservices -> namespaces -> classes> methods> ... The question is, what is the difference between a system and a module? And the author shows that the difference is not in physical or logical boundaries. The author refers to the classical definition of modules (self-contained, called by other elements, can be compiled separately). And then the author says that the components and modules differ in purpose - division into components solves the current problem of the system, and division into modules helps solve the future problem when the system will evolve. Then the author talks about the definition of complexity from the author of the Cynefin framework, where complexity depends on the ease of establishing a relationship between cause and effect. Conventionally, if we can predict the consequences of our actions in a system, it is a simple system. But if we need experiments to determine the relationship, then a complex system In software design, complexity can be local or global. (conditionally the complexity within the module or the complexity of the relationships between the modules). The locality/globality of complexity depends on the point. Modularity and complexity are multilevel phenomena that can be observed at different levels of abstraction. Next, the author shows the complexity metrics given by uncle Bob in his book Clear Architecture. By the way, I've already done a brief sammari part of it about the design of modules. here. Vlad shows how to hack abstractness, stability, distance from the main sequence. Although if you want, you can want any metrics, and therefore metrics of Vlad himself, which he offers further:) Vlad proposes a method of evaluation through an integration model, which is based on an assessment of the relationship between the elements of the system. This model combines coupling/connascence/cohesion. The point is that we need to estimate the intensity of the exchange between the module over these connections. The model includes four levels that go from the most terminal cases to the optimal ones. (The amount of general knowledge between modules decreases.)

1. Intrusive coupling Intrusion integration when encapsulation boundaries are violated and the dependent module accesses the internal implementation of another module. Examples: database interaction, using reflection to access private properties.
2. Functional coupling Relationship through function or business requirements. Interestingly, there is no need for a link in the code.
3. Model coupling communication through a common business domain model, data structure. It is difficult to evolve a common model.
4. Contract coupling - contractual communication (API). In DDD, there are methods such as published language, anti-corruption layer, etc.

How to use this model I rock In the continuation of the post, plus I recommend another book by Vlad "Learning DDD" ("Studying DDD - subject-oriented design")about which I'm much told earlier.

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes #Management