Reflection on building system architecture based on patterns

1. Build a system architecture based on user requirements and use cases for business processes. You can use commonality/variability for Public/Variability Analysis. Its core idea is to classify the concepts in the problem field, express those seemingly different but essentially belong to a class with an abstract concept, and then build an architecture based on these abstract concepts.

2. The architecture should be able to provide guidance for further work, and the architecture should not be too vague or extensible. At the same time, the architecture cannot be too abstract and vague, so that the guidance is of little significance or too specific. In this case, the architecture falls into details and thus lacks universality.

3. object-oriented design principles-class design principles:
The open closed principle OCP: a module should be open in terms of scalability, and should be more modified
Closed.
The liskov substitution principle LSP: The subclass should be able to replace the parent class and appear anywhere the parent class can appear.
The dependency inversion principle dip: when designing a business, the dependencies related to the specific business should be exhausted.
Instead of relying on specific classes. The specific class is only responsible for the implementation of the relevant business. The modification of the specific class does not affect
Dependencies related to specific services. Therefore, we should try to define business methods in interfaces or abstract classes during business design.
And implement the business method through a specific implementation class (subclass). Modifications to the Business Method content will not affect the operation.
When the business method is called.
The interface segregation principle ISP: Compares multiple interfaces related to specific customer classes with one
It is better to use interfaces that cover multiple business methods. The essence of this principle is quite simple. If you have one
Class, create a specific business interface for each customer, and then make the customer class inherit multiple specific business interfaces than directly loading the customer's
All methods are required.
Single Responsibility Principle (SRP ): For a class, there should be only one reason for its change. When constructing an object
Different duties are separated into two or more classes to ensure that there is only one reason for this change. Benefits: improved cohesion and reduction
Low coupling.

4. Hierarchy of design patterns:
1) Level 1 realm: Think That mode is a solution
2) Level 2 realm: In addition to understanding the solution provided by the model, we can also recognize some guiding principles behind the model, such
Interface Programming; use combinations instead of inheritance; discover and encapsulate changes;
3) Level 3 realm: recognizing patterns is actually a relationship that helps ease the "conflicting power" inside the system ".