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

This article mainly introduces the relevant knowledge of "what are the common software development and design patterns". The editor shows you the operation process through an actual case, and the operation method is simple, fast and practical. I hope this article "what are the common software development design patterns" can help you solve the problem.

Hierarchical mode

The hierarchical pattern is probably one of the most famous software architecture patterns. Many developers use it without knowing the name. The idea is to split your code into "layers", where each layer has some responsibility and provides services to higher levels.

There are no predefined number of layers, but these are the layers you see frequently:

Presentation (presentation or UI layer)

Application (application layer)

Business (business or management)

Persistence (persistence or data access layer)

Database (database tier)

The idea is that the user starts a piece of code in the presentation layer by performing some actions, such as clicking a button. The presentation layer then invokes the underlying layer, the application layer. Then we go into the business layer, and finally, the persistence layer stores all the content in the database. So the higher layer depends on and invokes the lower layer.

Depending on the complexity of the application, you will see the corresponding variants. Some applications may ignore the application layer, while others may add a cache layer. You can even merge the two layers into one. For example, the ActiveRecord pattern combines the business layer with the persistence layer.

Each layer of responsibility

As mentioned earlier, each layer has its own responsibility. The presentation layer contains the graphical design of the application, as well as any code that handles user interaction. You should not add logic to this layer that is not specific to the user interface.

The business layer is where you specific the model and logic to the business problem you are trying to solve.

The application layer lies between the presentation layer and the business layer. On the one hand, it provides an abstraction so that the presentation layer does not need to know about the business layer. In theory, you can change the technology stack of the presentation layer without changing anything else in the application (for example, from WinForms to WPF). On the other hand, the application layer provides a place to place some coordination logic that is not suitable for the business or presentation layer.

Finally, the persistence layer contains the code to access the database layer. The database layer is the underlying database technology (such as SQL Server,MongoDB). The persistence layer is a collection of code that manipulates the database: SQL statements, connection details, and so on.

Advantages

Most developers are familiar with this pattern.

It provides an easy way to write well-organized, testable applications.

Shortcoming

It often makes it difficult to separate monolithic applications later.

Developers often find themselves writing a lot of code to pass through different layers without adding any values to those layers. If all you do is write a simple CRUD application, then the hierarchical model may be too much for you.

Suitable for the scene

Standard line of business applications, not just CRUD (write, read, modify and delete) operations

Microkernel

Microkernel mode or plug-in mode is useful when your application has a set of core responsibilities and a set of interchangeable parts. The microkernel will provide the entry point and general flow of the application without knowing what the different plug-ins are doing.

One example is the task scheduler. The microkernel can contain all the logic for scheduling and triggering tasks, while plug-ins contain specific tasks. As long as plug-ins follow predefined API, the microkernel can trigger them without knowing the implementation details.

Another example is workflow. The implementation of workflow includes concepts such as the order of different steps, evaluating the results of steps, and deciding what to do next. The specific implementation of the steps is not important to the core code of the workflow.

Advantages

This model provides a lot of flexibility and extensibility.

Some implementations allow you to add plug-ins while the application is running.

Microkernels and plug-ins can be developed by independent teams.

Shortcoming

It is difficult to decide what is a microkernel and what is not.

Predefined API may not be suitable for future plug-ins.

Suitable for the scene

Applications that obtain data from different sources, convert the data and write it to different destinations

Workflow application

Task and job scheduling application

CQRS

CQRS is an acronym for the separation of command and query responsibilities (Command and Query Responsibility Segregation). The core concept of this pattern is that the application has read and write operations that must be completely separated. This also means that the model used for write operations (commands) will be different from the read model (query). In addition, the data will be stored in different locations. In a relational database, this means that there will be tables for command models and tables for reading models. Some implementations even store different models in completely different databases, such as the SQL Server of the command model and the MongoDB of the read model.

This pattern is usually combined with event procurement, which we will describe below.

How does it work? When the user performs an action, the application sends a command to the command service. The command service retrieves all the data it needs from the command database, performs the necessary operations, and stores it back to the database. It then notifies the reading service so that the read model can be updated. The process is as follows.

When the application needs to display data to the user, it can retrieve the read model by calling the read service, as shown below.

Advantages

The command model can focus on business logic and validation, while the read model can be tailored to specific scenarios.

You can avoid complex queries (for example, joins in SQL), which makes reading more efficient.

Shortcoming

Keeping commands and reading models in sync can become complicated.

Suitable for the scene

Applications that expect a lot of reads

Applications for complex domains

Event procurement

As I mentioned above, CQRS is usually closely related to event procurement. This is a pattern that does not store the current state of the model in the database, but rather stores events that occur in the model. Therefore, when the customer name changes, you do not store the value in the name column. You will store a "NameChanged" event with a new value (or an old one).

When you need to retrieve the model, you will retrieve all its stored events and reapply them on the new object. We call it the rehydration object.

The realistic analogy of event procurement is accounting. When you add an expense, you do not change the value of the total. In accounting, a new line is added and the action is performed. If an error occurs, just add a new line. To make your life easier, you can calculate the total each time you add a line. This total can be thought of as a read model. The following example should be clearer.

You can see that we made an error when adding the invoice 201805. We added two new lines instead of changing them: first, one line was used to cancel the error line, then a new correct line. This is how event procurement works. You will never delete events because they were undeniable in the past. To correct the situation, we added a new event.

In addition, notice how we have cells with a total value. This is just the sum of all the values in the cell above. In Excel, it updates automatically, so you can say it synchronizes with other cells. It is a reading model that provides a simple view for the user.

Event procurement is often used in conjunction with CQRS because rehydration of objects can have an impact on performance, especially if the instance has many events. Fast reading mode can significantly improve the response time of applications.

Advantages

The software architecture pattern can provide out-of-the-box audit logs. Each event represents the manipulation of data at some point in time.

Shortcoming

It requires some discipline because you can't fix the wrong data with simple edits in the database.

It is not easy to change the structure of events. For example, if you add an attribute, the database still contains events that do not have that data. Your code needs to deal generously with this missing data.

Suitable for the scene

Events need to be published to an external system

Will be built with CQRS

Audit logs that require changes to the data

Micro service

When you write an application as a set of micro services, you are actually writing multiple applications that can work together. Each microservice has its own unique responsibility, and the team can develop them independently of other microservices. The only dependence between them is communication. Because microservices communicate with each other, you must ensure that the messages sent between them remain backward compatible. This requires some coordination, especially when different teams are responsible for different microservices.

A picture can explain.

In the figure above, the application invokes a central API to forward the call to the correct microservice. In this example, there are separate services for user profiles, inventory, orders, and payments. You can imagine that this is an application where users can order something. Individual microservices can also call each other. For example, the payment service can notify the order service when the payment is successful. The order service can call the inventory service to adjust inventory.

At present, there is no clear definition of the scale of microservices. In the previous example, the user profile service might be responsible for the data, such as the user's user name and password, as well as home addresses, avatars, favorites, and so on. You can also divide all these responsibilities into a smaller option micro-service.

Advantages

You can write, maintain, and deploy each microservice separately.

The micro-service architecture should be easier to extend because you can only extend the micro-services that need to be extended. There is no need to extend the infrequently used parts of the application.

It is easier to rewrite parts of the application because they are smaller and less coupled to other parts.

Shortcoming

Contrary to what you might expect, it's actually easier to start writing well-formed macros and break them down into micro-services later. With the advent of microservices, many additional issues come into play: communication, coordination, backward compatibility, logging, and so on. Teams that miss the necessary skills to write well-structured macros may find it difficult to write a good set of microservices.

A single action of a user can be done through multiple microservices. There are more failure points, and when problems arise, it may take more time to identify them.

Suitable for:

Some parts of the application will be used intensively and need to be scaled

A service that provides functionality for several other applications

If combined into a whole, then the application will become very complex

Applications can define clearly bounded contexts

This is the end of the introduction of "what are the common software development design patterns". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

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.