From Architecture to Code: Analysis of the Latest Trends in Software Development

Image for post
Image for post

By Leijuan

This article is based on a webcast lecture delivered by Chen Libing (Leijuan), a senior technical expert from the Alibaba Cloud Native team. In this lecture, he talked about what he considered to be the trends in software development in terms of domain-driven design (DDD), Reactive, Service Mesh, and code intelligence.

Trends in Software Architecture and Design

Image for post
Image for post

In this article, we will also explain why the technologies related to DDD occupied an important place in the InfoQ report. In addition, we will further describe other related technologies, including Service Mesh.

Domain-Driven Design (DDD)

Image for post
Image for post

Previously, DDD included concepts such as layered architecture and event-driven design. However, when you divided a single application into multiple applications, DDD had a big problem in the communication between these applications. We used bounded context mapping in DDD to address the problems in the communication between two bounded contexts. The decoupling method in DDD that we mentioned earlier provided a theoretical foundation for message-based asynchronous communication. However, we lacked the specific technology stacks required for the implementation process. The specific implementation methods may vary by language, because some languages support pure asynchronous operations and may contain built-in coroutine support. Therefore, we will select different solutions in different technology stacks. This lecture focuses on the Java technology stacks, but please note that Reactive is not exclusive to Java.

Image for post
Image for post

The advantage of Reactive is that the communication between two bounded contexts becomes a technology stack that we can implement by using Reactive. Domain-Driven Design in Java (jDDD) is a new project that is implemented based on Spring Data. jDDD is also a software development kit (SDK), which is designed to enable developers to present DDD ideas in code by using SDK. As we mentioned earlier, microservices rely on bounded contexts to identify boundaries and divide applications. In addition, both could-native and Function as a service (FaaS) solutions include event-driven architecture, but the concept of event was put forward early in DDD. If your solution involves events or asynchronous operations, you must pay attention to the relationship between events and DDD. Currently, we have mature technologies in this aspect. Please also note that in the combination of DDD and CQRS, CQRS implements read/write splitting. For example, a MySQL database provides a primary/secondary mechanism, in which the primary and secondary databases deal with writing and reading respectively. Similarly, CQRS also assumes an important role in DDD. At present, DDD is a mainstream architecture and design method, which enables us to address some design issues.

Reactive

Image for post
Image for post

RSocket

If you understand the semantics of Reactive, you will know the backpressure mode. Backpressure is similar to circuit breaking protection, and both mechanisms are designed to address the throttling issue. If the consumers or the service provider of an application get overwhelmed due to sudden bursts of traffic, the application will undergo an avalanche or crash. In a message queue of the traditional mode, the message provider actively pushed messages to the consumers. At that time, the provider continued pushing messages even though the consumers were unable to consume them. If this was the case, the system would become unstable because the consumers got overwhelmed.

Kafka, which came out later, implements the pull mode. Consumers can pull as many messages as they need, because Kafka supports accumulation of messages. However, time intervals must be set in pull mode. If this is the case, there is a problem: When no message is sent, the system will keep pulling messages from the broker, causing waste of network resources. Therefore, the backpressure in Reactive is implemented by adding a switch to the original message push model. With this switch, the system will stop pushing messages when the number of messages has reached a certain value. The advantage of this active push mechanism is its high performance without pulling messages or saving message consumer offsets. In short, with the backpressure mechanism, you can set the maximum number of messages that consumers can pull. Therefore, you can improve the performance within the limits and protect the message consumers.

Image for post
Image for post

RSocket has provided four communication models: request, response, publish/subscribe, and log collection. After you divide an application by using DDD, the applications need to communicate with each other. RSocket has not only provided four models that cover almost all communication scenarios between applications, but also provided metadata push. You can perform all cluster changes and throttling by using metadata push.

RSocket also supports peer-to-peer communication. Traditional communication models use the client/server mode. However, RSocket does not distinguish between client and server, which means that both communicating parties can send messages to each other. The design model and concept of RSocket that we mentioned earlier aim to address various problems in the communication between applications in Reactive. Although RSocket has not been widely used, many technical communities already support this solution. For example, support for RSocket has been added to Spring V5.2. The released communication protocol is based on Reactive. However, if there are database operations or other operations that are not asynchronous, you must make some changes. Therefore, the support for Reactive has been improved in Spring Boot 2.3, which is released in this year. For example, Spring WebFlux can be used in the gateway layer to guarantee the reactive design.

The middleware, communication models, and NoSQL products support asynchronous operations and address high-concurrency issues. It has been a long time since these features were added to Spring. In addition, databases also assume a key role in software development. Every Java programmer must first set up connection pools when they access databases. We must take the database design into account and think about questions such as which connection pool can provide the highest performance. This is because if database access is not an asynchronous operation, you must establish multiple connections to address the concurrency issue. Therefore, support for asynchronous database operations has been added to R2DBC in Spring. Currently, Spring can support asynchronous database operations, but we still have to wait for some time. This is because R2DBC is a specification and driver like JDBC, but at present there is only one R2DBC-based framework, which is Spring Data R2DBC. In contrast, there are many JDBC-based upper-layer frameworks, such as Hibernate and MyBatis. Therefore, many developers in China prefer MyBatis. If you intend to implement asynchronous methods, you will basically apply a fully asynchronous pattern, which stretches from the gateway layer protocol that was initially connected to the NoSQL database and includes the storage file system. Currently, we have mature technologies in this aspect.

Service Mesh

Distributed Application Runtime (Dapr), which came out later, is different from the “Istio and Envoy” architecture. An Envoy sidecar can be considered as a proxy that is designed to connect services. In contrast, a Dapr sidecar is more than a proxy. It can help developers do many things, such as implementing applications by using a new programming language. However, Kafka or NoSQL databases do not provide language-specific SDKs.

Even when these SDKs are provided, they are unstable. Therefore, your choices of new technologies are constrained. For example, the most stable SDKs for big data platforms, such as HBase and Hadoop, are related to Java. Dapr is a runtime that interacts well with external systems. For example, a Dapr sidecar can not only communicate with gRPC, but also communicate with Kafka and then transfer the data obtained from Kafka to gRPC. In addition, with Dapr, developers do not need to understand the underlying details of communication protocols.

Image for post
Image for post

This design is better than the “Istio and Envoy” architecture. This is because if a sidecar only acts as a proxy, a large amount of data processing work must be done on the client side. If you need to do this work on a proxy, you must use a Dapr sidecar instead, which is more complex. In addition, Alibaba has recently been attempting to implement RSocket Broker, which is built upon Reactive Mesh and is structurally different from sidecars. Most sidecars that are based on message-driven or event-driven architectures only need to send messages.

In contrast, RSocket Broker has provided a comprehensive package of communication protocols between applications. Therefore, you do not need to select other communication protocols. We recommend that you select one of the preceding three technical solutions according to your actual situation, because there is no absolutely correct technology selection. At present, however, the “Istio and Envoy” architecture has gained popularity among the majority of developers, because it has provided convenient Kubernetes integration and comprehensive infrastructure.

FaaS

Image for post
Image for post

FaaS WebAssembly is also a current trend in technologies and is also integrated with FaaS. As we all know, if you do not frequently use FaaS, you will wait for some time when you start containers. In some scenarios, however, there are strict limits on waiting time. If this is the case, it is often difficult to implement solutions that use traditional containers. However, WebAssembly can act as a hook for functions and meet the preceding requirements. Meanwhile, WebAssembly is also a new specification released by World Wide Web Consortium (W3C). Therefore, WebAssembly has joined HTML, CSS, and JavaScript, which are formerly called the “Big Three” web development tools. Together they constitute the new “Big Four”. In addition, in terms of FaaS, WebAssembly has gained support from recently released Deno. Many developers are concerned about Rust, and Deno can effectively support Rust. Therefore, Deno is the runtime that many developers select for FaaS.

Code Intelligence

Image for post
Image for post

Code Generation and IDE

Image for post
Image for post

Original Source:

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store