To what extent should the software architecture be designed?

Because of the complexity of the software system, it is difficult for ordinary people to clearly understand the entire system, so the concept of architecture view will appear, the main driving force or principle of architecture view is to divide and conquer it.

Divide and conquer two types

1.
Divide and conquer the problem based on the depth of the problem, that is, do not take the problem as deep as possible, so be careful and try it out. For example, defining interfaces between modules is like this. First, we do not consider how to implement interfaces, but define the contract for communication between modules.

2.
Divide and conquer the problem based on the breadth of the problem, that is, not to study the whole problem first, but to study part of the problem, divide the problem and break through each other. For example, when the MVC Architecture is used for development, each layer is an in-depth part.

What method should the software architecture adopt?

The so-called architecture design is the most important design decision on how to build software. These decisions usually focus on what parts of the system are divided into and how each part interacts.

The so-called detailed design is designed internally for each part.

Therefore, we can say that the architecture design should be divided and governed by the depth of the problem, focusing on the overall design of the system; while the detailed design should be divided and governed by the breadth of the problem, focusing on how each module is implemented.

Software Architecture is the foundation of team development

On the one hand, the architecture starts from the overall situation and makes decisions on major technical issues. It constructs a solution with a certain level of abstraction, rather than all the details, this effectively controls 'technical complexities '.

On the other hand, because the architecture contains information about how each element interacts with each other, different modules can be allocated to different groups for development, the architecture plays the role of a "bridge" and a "cooperation contract" in the middle.

To what extent should the architecture be designed?

1.
The degree of architecture design varies depending on different projects and development teams.

2.
The software architecture should provide developers with adequate guidance and restrictions.

What is a high-availability software architecture?

A high-to-high architecture refers to an architecture design that does not provide sufficient guidance and restrictions for developers.

Dangers of high-to-high architecture

1.
Without guidance and restrictions from the architecture, developers may encounter many problems after entering the development stage, and may cause management confusion and low communication and collaboration efficiency.

2.
Global design decisions that are critical to software quality are quickly decided by the delay during the split-head development period, seriously reducing the quality of software products.

3.
Failure to resolve major technical risks may cause failure of the entire project.

4.
Team members have great opinions on architects and their team morale is low.

Common high-to-high architecture

1.
The main architecture view is missing.

The more complex the system is, the more you should design the architecture from multiple aspects. If guidance on certain roles of the team is omitted, the development progress and development quality will be adversely impacted. If this is the case, design the missing architecture view.

2.
It is not in-depth enough.

The architecture design is not deep enough and remains in the concept stage. Although the conceptual architecture is 'useful ', it is often not 'adequate enough' to easily leave significant technical risks to future development. If such a phenomenon exists, design decisions must be made at the technical level.

3.
Non-real Hierarchical architecture.

It refers to those who claim to adopt a layered architecture, but only use a layered hierarchy to divide their duties with full mind, without planning the interaction interfaces and interaction mechanisms between layers. If such a phenomenon exists, we should step by step to clarify the interaction interfaces and mechanisms between layers.

References
Software Architecture Design