Xiao Yin Lele advanced architect

preface

Each architect has his or her own understanding of the system application architecture. A number of application architecture artifacts have emerged over the long term in technical practice. But it is often thought, without real landing products. COLA’s sudden emergence provides excellent practice for application architecture implementation.

COLA’s primary goal is to provide a simple set of “guidelines and constraints” for application architectures that can be replicated, understood, landed on, and controlled for complexity.

At present, COLA has developed to 4.0. We will conduct a new reorganization and return to our original intention to make COLA truly become the best practice of application architecture and help the majority of business technical students to get rid of the mire of sauce jar code.

The nature of application architecture

From the official overview. The meaning of architecture is element structure, which is an important element of architecture, and structure is the relationship between elements. The meaning of application architecture is to define a good structure to govern application complexity, reduce system entropy, and move from arbitrary chaos to tightly ordered state.

As you can see in the figure below, entropy is a measure of how chaotic things are. The neater the cleaner, the lower the entropy.

A good organizational structure will follow certain architectural patterns, and most organizations will design their own structures according to their functions and businesses. If you go the other way and insist on putting sales, finance and technical people in one department, it seems strange.

Similarly, good application architectures follow common patterns, whether hexagonal architecture, onion ring architecture, clean architecture, or COLA architecture, all advocate business-centric, decouple external dependencies, and separate business complexity from technical complexity.

The essence of application architecture is to extract commonness from complex business systems, find the best common mode to solve business problems, provide unified cognition for developers, and manage confusion. Helping applications “move from clutter to order” is what the COLA architecture was designed for. Its core responsibility is to define a good application structure and provide best practices.

COLA Architecture – Layered structure

All complex systems will present a hierarchical structure, and the application system should also deal with complex business logic in a hierarchical manner, with the lower layer shielding the details from the upper layer, and each layer performing its own duties and separating concerns.

For a typical business application, COLA defines the following layers, each with specific responsibilities:

1) Adapter Layer: responsible for routing and adaptation of front-end display (Web, Wireless, WAP). For traditional B/S system, Adapter is equivalent to controller in MVC;

2) Application Layer: mainly responsible for obtaining input, assembling context, parameter verification, calling domain Layer for business processing, and sending message notification if necessary. The layer is open, and the application layer can bypass the domain layer and directly access the basic implementation layer.

3) Domain Layer: it mainly encapsulates core business logic and provides business Entity and business logic calculation for App Layer through Domain Service and Domain Entity method. The domain is the core of the application, independent of any other level;

4) Infrastructure Layer: mainly responsible for handling technical details, such as CRUD of database, search engine, file system, RPC of distributed service, etc. In addition, the burden of Domain preservation falls here, as external dependencies need to be escaped by the Gateway before they can be used by the App and Domain layers above.

COLA Architecture – Package structure

Layering is a responsibility division of large granularity, which is too coarse. We need to go down another layer to refine the granularity of the package structure, so as to better guide our work.

Taking a stack of toys as an example, layering is like taking a shelf, and subcontracting is like placing multiple storage boxes on each shelf. The so-called cohesion is to put toys with similar functions in a box, which makes the application structure clear and greatly reduces the cognitive cost and maintenance cost of the system.

The current structure of COLA has been formed through continuous iterations:

The brief function description of each package structure is shown in the following table:

level The package name function Will choose
Adapter layer web Controller that handles page requests no
Adapter layer wireless Handle wireless adaptation no
Adapter layer wap Handle waP side adaptation no
The App layer executor Process request, including command and query is
The App layer consumer Handling external messages no
The App layer scheduler Handling Scheduled Tasks no
Domain layer model The domain model no
Domain layer ability Domain capabilities, including DomainService no
Domain layer gateway Domain gateway, decoupling tool is
Infra layer gatewayimpl The gateway is
Infra layer mapper Ibatis database mapping no
Infra layer config Configuration information no
Client SDK api The API exposed to the service is
Client SDK dto Service external DTOS is

Consider both functional and domain dimension package structure definitions. According to the subcontracting strategy of two dimensions, domain and function, the top-level package node as shown in the figure below is the domain name, and below the domain, the package structure is divided by function.

After several iterations, we defined a relatively stable and reliable application architecture: COLA 4.0

COLA Archetype

Good application architectures follow some common patterns, whether hexagonal architecture, onion ring architecture, clean architecture, or COLA architecture, all advocate business as the core, decouple external dependencies, and separate business complexity from technical complexity.

What differentiates the COLA architecture from these is that it provides tangible tools and practical guidance in addition to ideas.

In order to quickly create applications that meet the COLA architecture, two Archetypes are provided under Cola-Archetypes.

  1. One is archetype: cola-archetype-service for creating pure back-end services.
  2. Archetype: cola-archetype-web is a web application for creating adapter and back-end services as one.

COLA Components

In addition, it provides some very useful generic components that can help improve r&d efficiency.

These functional components are grouped under cola-Components. So far, the following components have been precipitated:

Component name function version Rely on
cola-component-dto DTO formats are defined, including paging 1.0.0 There is no
cola-component-exception Exception formats are defined, including BizException and SysException 1.0.0 There is no
cola-component-statemachine State unit 1.0.0 There is no
cola-component-domain-starter Spring-hosted domain entity components 1.0.0 There is no
cola-component-catchlog-starter Exception handling and logging components 1.0.0 Exception, dto components
cola-component-extension-starter Extension point component 1.0.0 There is no
cola-component-test-container Test container components 1.0.0 There is no

How to Use COLA

Open source: github.com/alibaba/COL…

  1. Install the cola archetype

    Download the source code from cola-archetypes and run MVN Install.

  2. Install the cola components

    Download the cola-Components source code locally, then run MVN install locally.

  3. Create an
    MVN archetype: generate-dgroupid =com.alibaba. Demo-dartifactid = demoweb-dversion = 1.0.0-snapshot -Dpackage=com.alibaba.demo -DarchetypeArtifactId=cola-framework-archetype-web -DarchetypeGroupId=com.alibaba.cola - DarchetypeVersion = 4.0.0Copy the code

    If the command is executed successfully, the following application code structure is displayed:

    Note: you can also use the ali cloud application generator: start.aliyun.com/bootstrap.h… Generate cola application.

  4. Run the application

    First run MVN install in the demoWeb directory (you can add the -dskiptests parameter if you don’t want to run tests). Then go to the start directory and run MVN spring-boot:run. If SpringBoot is successfully started, the SpringBoot startup success page is displayed.

    Generated applications, has achieved a simple Rest requests, you can enter http://localhost:8080/helloworld in your browser for testing.