[Architecture mode practice] How to prevent failure of third-party services/components from interfering with development and testing progress

I got up today and found the sun shining. I got stuck in my office on Sunday, but I didn't have a chance to see the warmth of the sun at noon in winter.

Leaning on the bed, I stretched out and held up the enterprise application architecture model that had never been able to read. at that moment, the sun shines on books, although some dazzling, but does not hinder a small sense of satisfaction quietly born.

Chatting with a colleague the day before, I mentioned a project that I participated in for a period of time. One feature of this project is to use a large number of third-party interfaces in different forms, is a "legendary" enterprise-level application: during the previous round of testing, some of the interfaces were frequently used as machines or service interruptions, as a result, the process of testing and modifying Bugs has been delayed for a long time. As a result, my colleagues proposed to make some alternatives to these interfaces in some stages of development and testing, replace the dependency on the testing environment of third-party interfaces.

Because this conversation has not completely slipped away from the brain, I am thinking about finding some relevant content in the book. the first step is to find chapter TER 18 base patterns. The first step is gateway, which means to encapsulate some third-party services and resources in Gateway mode. this document provides an example of sending a specific business message to a message queue. It aims to clarify the advantages of gateway mode in simplifying the call and clarifying the call.

The so-called simplified call, because the service/resource users do not need to care about the details of the original API, all of them use a unified, sufficient API to access a class of service/resource, such as XML, such as relational databases and various message-oriented middleware.

The so-called explicit call takes sending a message to a message queue as an example. Generally, the APIs of message queue middleware are abstract enough to provide universality. The APIS themselves do not contain any specific business meanings and instructions. however, for the user who calls the message sending API, a method name with a clear indication, some typed and quantitative method parameters, and then the method that checks the range of input parameters in the method, it does provide a better programming experience, which is conducive to rapid selection of appropriate methods in the development phase and unit testing, as shown in the example sendconfirmation (ID, amount, symbol ).

Because the gateway mode decouples service/resource providers and users, it can be used in some stages of development/testing to bypass dependencies on third-party interface testing environments. to achieve this purpose, the Service stub mode also appeared in Chapter 18, which is useful.

In the next week's work, I will spend some time classifying the third-party interfaces currently used in the system to find the appropriate stub Method for different types of interfaces. therefore, I want to further introduce the service stub model. After some practices, I hope to summarize more valuable things and write them down again.