Shulou(Shulou.com)06/03 Report--

This article focuses on "what are the principles of software architecture packages and namespaces". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what are the principles of software architecture packages and namespaces.

Spaghetti architecture

Some of the project structures I am involved in are completely arbitrary and do not reflect the architecture or the domain. If my question is "where should I put this value object?", the answer is "just put it in the src directory." If my question is "where is the service that completes this logic", the answer is "search with IDE". This means no thought at all about how to organize the code.

The hidden danger here is great, because there is no use of packages to achieve modularization at all, and high-level code relationships and flows do not follow any logical structure at all, which will lead to modules with high coupling and low cohesion. In fact, there may be no module partition at all, and the code that should belong to a module is scattered throughout the code base. Such a code base is the so-called spaghetti code, or spaghetti architecture!

Maintainable code base

Having a maintainable code base means that we can get the biggest conceptual changes with minimal code changes. In other words, if we need to modify one code unit, the other code units should be modified as little as possible.

This brings obvious advantages:

Because less code is affected, it will be easier to modify.

Because less code is affected, changes will be faster.

Because there is less modified code, the chance of problems will be reduced.

Encapsulation, low coupling, and high cohesion are core principles for maintaining code isolation, making a maintainable code base possible.

Encapsulation

Encapsulation is the process of hiding the internal representation and implementation of a class.

That is, the implementation is hidden so that the internal structure of the class can be changed at will without affecting the implementation of other classes that use the class.

Low coupling

Coupling involves the relationship between code units. If the modification of one module leads to the modification of another module, we say that the two modules are highly coupled. If a module can be independent of any other module, we say it is loosely coupled. By providing a stable interface to effectively hide the implementation from other modules, the goal of loose coupling can be achieved.

Advantages of low coupling

Maintainability-modifications are limited to one module

Testability-Unit testing involves as few modules as possible

Readability-as few classes as possible that require careful analysis

High cohesion

Cohesion refers to the measure of functional relevance within a module. Low cohesion means that the module has some different and unrelated responsibilities. High cohesion means that the functionality of a module is similar in many ways.

The advantages of high cohesion

Readability-(closely) related functions are contained in a module

Maintainability-debug code only in one module

Reusable-the function of the class is very focused and will not be filled with many useless functions

Influence on structure

These principles apply to classes, but they also apply to combinations of classes. A combination of classes is usually called a package, but we can break it down into more details, calling it a module if the grouping is purely functional (such as ORM) and a component if it is for domain considerations (such as AccountManagement). These definitions are consistent with those described by Bass, Clements and Kazman in their book Software Architecture in Practice.

We can and should make the package highly cohesive and low-coupled, so that we can do so:

Modify one package without affecting other packages to reduce problems

Modify one package without the need to modify other packages to speed up delivery

Let the team focus on specific packages, resulting in faster, more robust, and better designed changes

There are fewer dependencies and conflicts between team development activities, increasing productivity.

Considering the relationships between components more carefully, let's better model the application as a whole and deliver higher-quality systems.

Concept encapsulation

I think if our project structure reflects both architecture and domain in some way, the maintainability of our code base can be greatly improved. In fact, now I'm sure it's the only way to do it (when we're dealing with large and medium-sized enterprise applications).

If the code base is properly organized, there is only one place for a particular code unit to store. We may not know the exact location, but there must be only one logical path that allows us to find it.

Definition of package

Dividing classes into packages allows us to think about design at a higher level of abstraction. The goal is to fragment the classes in your application according to certain conditions, and then assign these fragments to the package. The relationship between these packages expresses the high-level organization of the application. Robert C. Martin 1996, Granularity pp. 3

To define the conceptually relevant code as a package, we need to achieve the goal. These packages are important because they define units of code that are conceptually relevant and independent of other packages, and the relationships between these packages.

The purpose of this is:

Understand the relationship between code units

Maintain the logical relationship between code units

Implement a code package with high cohesion and low coupling

ReFactor the code package with little or no impact on the application

Replace the implementation of the code package with little or no impact on the application

The principle of subcontracting

We should follow the package partition principle put forward by Robert C. Martin in 1996 and 1997 and other principles to achieve the goal, mainly CCP (Common Closure Principle, common closure principle), the CRP (Common Reuse Principle, common reuse principle) and SDP (Stable Dependencies Principle, stable dependency principle).

The packet partition principle proposed by Robert C. Martin:

Packet cohesion principle

REP-reuse publication equivalence principle: the granularity of reuse is equivalent to the granularity of publication

CCP-Common closure principle: classes that are modified together should be placed in a package

CRP-Common reuse principle: classes that are reused together should be placed in a package

Packet coupling principle

ADP-acyclic dependency principle: loops cannot appear in the dependency graph of a package

SDP-stable dependency principle: dependence should move in the direction of stability

SAP-stable abstraction principle: the higher the level of abstraction, the higher the stability

To use SDP properly, we should define the conceptual units (components) of the code and the layering of components, so that we can figure out which components should understand (depend on) other components.

However, if the boundaries of these components are not clear enough, we will mix the otherwise unrelated code units and couple them into spaghetti code, which will eventually be unmaintainable.

For these boundaries to be clearly presented, we need to put conceptually related classes in the same package, just as we put conceptually related methods in the same class. At the package level, we can only distinguish them by folders whose names have some meaning in the domain (for example, UserManagement, Orders, Payments, etc.). At the lowest level, that is, the leaf nodes in the package, we classify them by functional scope (for example, Entity, Factory, Repository, etc.) if necessary.

The following question can help us reflect on how to design low-coupling components:

"if I want to remove a business concept, can I delete all the code of the business concept by deleting its component root directory and the rest of the application will not be destroyed?"

If the answer is yes, then we have a well-decoupled component.

For example, in the command bus architecture, commands and processors cannot work without each other, and they are conceptually and functionally bound together, so if we need to remove the logic, we need to remove them together. If they are in the same place, we only need to delete a folder (we don't really want to delete the code, but just use this way of thinking to help us get decoupled and cohesive code). So, following the principles of CCP and CRP, the command should be placed in the same folder as its processor.

Any code can only exist in a logical location, which is clear even for beginners and beginners in the project. This avoids contradictory, confusing, repetitive code and developer frustration. If we need to search for code because it is impossible to find it where it should be, and / or it is difficult to understand which code is related to the code we are working on. Then our project structure is very bad, or even worse, the structure is very bad.

Screaming architecture

The scream architecture is the idea of Robert C. Martin, which basically shows the idea that the architecture should tell us clearly what the system does: its main area. Then the first-level directory that appears in the source folder should naturally be related to the domain concept, that is, the topmost bounded context (for example, patient, doctor, appointment, etc.). They should be independent of the tools used by the system (e.g., Doctrine, MySQL, Symfony, Redis, etc.), independent of the functional blocks of the system (e.g., repository, graphics, controller, etc.), and independent of the communication mechanism (HTTP, console, etc.).

Your architecture should be presented to the system, not the framework used by the system. If you are building a health care system, the first image of the new programmer when he sees the source code repository should be: "Oh, this is a health care system." -- Robert C. Martin 2011, Screaming Architecture

This is actually a simpler way to understand the principles of packet partitioning that he published 15 years ago, which I have explained before. This style of subcontracting is also called "subcontracting according to characteristics".

At this point, I believe you have a deeper understanding of "what are the principles of software architecture packages and namespaces". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.