One of. Net-based architecture designs

In my opinion, to design a good system architecture, consider the following:

0. limits the application boundaries of the system architecture

The system architecture that meets all application scenarios means that there is no architecture. It is highly risky to design a large and comprehensive system architecture at the beginning, therefore, the best solution is to prepare different small-scale architectures for different application scenarios. after a certain period of time of familiarity, accumulation, accumulation, re-thinking, reconstruction, and combination, the architecture I am using is gradually extended to meet the needs of large application scenarios. It started from the data access layer framework that only addresses or ing. After more than a decade of development, at present, it has reached a standard 4-layer architecture that meets general enterprise application business scenarios.

1. customer-centric

The most direct customer of the system architecture isProgramClerk, how can we make programmers more willing to use the architecture we designed? I think the most fundamental way is to think from the programmer's perspective and hide the real complexity of the system architecture, presents the functions of the system architecture to programmers in the simplest and most intuitive way based on the principle of minimum knowledge, so that they can truly appreciate the convenience and benefits brought by the architecture. For example, for service consumption, programmers prefer the following consumption methods:

Iservice service = servicefactory. Create <iservice> ();

Using (service as idisposable)

{

Service. callsomemethod;

}

To implement this call, the system architecture requires at least two complex tasks at the backend. One is to query the service address and description through the service bus and create a service proxy. The second is to block unregistered exceptions by injecting service instance dependencies. Otherwise, when a service call error occurs, only invalid service channel status exceptions will be thrown.

2. Changes increase.
It is always difficult to change, because it is very likely that things have been done by others. This requires us to consider some variable factors when designing the architecture, and solve future changes through modular design and plug-in design in an additional way.

For example, if we want to provide a service for sending and receiving text messages through SMS cats, there may be the following changes:

I. Future sending and receiving methods may change, from SMS cat to SMS Gateway

II. The text message processing method received in the future may change, such as the confirmation of temporary donations.

3. The number of text messages sent in the future may increase, for example, from one thousand messages per day to 1 million messages per day.

For the first one, we can define the SMS device interface at the beginning. When converting the sending method, we only need to add an SMS device interface implementation and modify the configuration file.

For the second message, we can define the short message arrival event interface and introduce the publishing and subscription mode. When there is a new short message processing method, we only need to add a subscriber of the Short Message arrival event.

For Article 3, we can introduce a message queue in the initial stage, send messages asynchronously, and design the service as stateless. When the existing service cannot meet the application requirements, you can solve this problem by adding physical servers to Server Load balancer.

3. High aggregation and low coupling

Programmers who work as technical personnel are always troubled by one thing or another. If they want to complete a function module, they have to communicate with too many other non-business personnel, the efficiency will be greatly reduced. We also need to consider this aspect when designing the architecture, hoping that programmers can work independently without dependency or dependency. For example, we introduce the Enterprise Service Bus and asynchronous event mechanism to reduce dependencies between services (functional modules) and provide self-registration services for services and processes, reduce developers' dependency on the management platform and deployment personnel.

4. global consideration of interoperability, security, measurement, and scalability

A good system architecture should free programmers from some basic and complex performance, quality, and security requirements, so that they can focus more on the implementation of upper-layer business needs.

For example, we can implement service Search and positioning in the system architecture to improve interoperability, and provide single-point logon and role-based authentication to achieve overall security, the measurement module is provided to achieve measurement of new services and provide service routing through simple configuration.AlgorithmTo achieve load balancing and improve scalability.

5. Achieve maximum reuse by providing basic modules, coding specifications, generating tools, sample projects, and training documents

The basic modules in many projects are the same. We can include these modules in the framework for reuse. Good experiences can be reused, such as exception handling, we can formulate processing policies at different layers of the data layer, data access layer, business processing layer, service layer, and UI Layer through coding specifications. The generation tool can help programmers save a lot of time to generate many standardCodeThrough the example project, you can more intuitively show programmers the solutions to general problems, as well as the Division, meaning, and implementation of project levels, the training documents can help programmers master some difficulties, such as transaction and lock processing and concurrent thread processing.