Ali sister REVIEW: Author Zhang Jianfei Alibaba senior technical experts, the Division for six years, he created the COLA. Hoping to explore a set of practical application architecture specification that is not superior on paper, but can be copied, it can be appreciated, the floor, you can control the complexity of the guidance and restraint. This article detailing his upgrade iteration of the COLA.
Many students and more than once I have feedback, our system is very confusing, mainly in:
-
Application hierarchy confusion: Do not know how to apply should be hierarchical, what should contain what the relationship between the components, the components are;
-
Lack of standardized guidelines and constraints: adding some new business logic do not know (what class, what package) on what, from what name should be more appropriate?
To solve these problems, what I create one of early heart COLA (https://github.com/alibaba/COLA) - The attempts to explore a set of practical application architecture specification that is not superior on paper, but can be copied , it can be appreciated, the floor, you can control the complexity of the guidance and restraint.
Since the COLA was born, I received a lot of comments and suggestions. At the same time, in my own practice, also found many deficiencies COLA 1.0, some redundant design is not necessary, but does not include some key elements. For example, I was recently thinking about complex business application architecture core and the code of governance is a reflection on the COLA 1.0.
Explore the combination of practice and ongoing reflection on the complexity of the treatment, I decided to conduct a comprehensive upgrade COLA, so with the current COLA 2.0.
From 1.0 to 2.0, a simple change is not just numbers, but also to upgrade the concept of architecture and design, the main point changes include:
-
The new layered architecture: Domain layer is no longer directly dependent on Infrastructure layer.
-
New components division: the component redefined and division, added new components, in addition to some old components (Validator, Convertor, etc.).
-
The new extension point design: the introduction of a new concept, so that expansion is more flexible.
-
The new second party library Positioning: second party library just DTO, is the Domain Model of lightweight expression and realization.
The new layered architecture
In COLA 1.0, we classic layered hierarchical structure shown below:
In the COLA 2.0, or these levels, but the dependency changes, Domain layer is no longer directly dependent on Infrastructure layer, but introduces the concept of a Gateway using DIP (Dependency Inversion Principle, dependency inversion) inversion layer and the Domain Infrastructure dependency layer, the relationship as shown below:
The benefit of this is the Domain layer will become more pure, completely free from dependence on technical details (as well as technical details bring complexity), just like the peace of mind to deal with business logic.
In addition, there are two benefits:
1. Parallel development: As long as the interface is good agreement between the Domain and Infrastructure, two students may have to write parallel code Domain and Infrastructure.
2. testability: No Domain which are dependent POJO classes, the test unit will be very convenient, very suitable for the development of TDD.
New components division
And the component definition module
First, let's be clear about the definition of the concept of component (Component), the component in Java (or in this article), its scope is the Java package (Package).
There is a word called module (Module), components and modules these two concepts is more prone to confusion. For example, in "Implementing Domain Driven Design", the authors say:
If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.
He is believed Module Package, I think this definition is confusing. Especially when using Maven, and in Maven, Module is an Artifact, usually a Jar instead Package. For example it comprises four COLA Framework Module:
<modules>
<module>cola-common</module>
<module>cola-core</module>
<module>cola-extension</module>
<module>cola-test</module>
</modules>
Indeed, Module and Component these two concepts are similar, it is likely to cause confusion. For example, there is a question on StackOverflow [1], is to ask the difference between Module and Component. The answer is to get the highest praise distinguished by Scope.
The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope.
The answer and my gut reaction is the same, that is larger than Module Component. Based on the above information, I am here to conduct some definitions Component Module and described herein, will comply with the following definitions and Notation (notation).
-
Module (Module): and Maven Module defined in consistent, simple to understand Jar. He expressed cube.
-
Component (Component): and in UML similarly defined, simple to understand Package. Represented by the UML components of FIG.
A Moudle usually composed of a plurality Component, and the relationship notation as follows:
COLA 2.0 Components
In the COLA 2.0, we redesigned components, introduces some new components, but also to some old components removed. The purpose of these changes is to make the application more clear structure, responsibilities components more clearly, in order to better provide development guidance and restraint.
The new component structure as shown below:
These components each have their own areas of responsibility, responsibility is an important component part of the COLA, that is to say above us "guidance and restraint." Detailed functions of these components are described below:
-
Second party library components:
-
api: the interface is stored in external applications.
-
dto.domainmodel: used for data transmission in the field of lightweight objects.
-
dto.domainevent: used for field event data transmission.
-
-
Application in components:
-
service: Facade interface implementation, no business logic, may include different terminal adapter.
-
eventhandler: processing arts event, including this domain and the extracellular domain.
-
executor: for processing command (Command) and query (Query), to complex business, and it may include Phase Step.
-
interceptor: AOP mechanism for handling all requests COLA provided.
-
-
Domain where the components:
-
domain: domain entities, allowing the inheritance domainmodel.
-
domainservice: field service, field capacity to provide a more coarse-grained.
-
gateway: the gateway interface external dependence, including storage, RPC, Search and so on.
-
-
Infrastructure in the components:
-
config: configuration information related.
-
message: message processing related.
-
repository: storage-related, specialized gateway is mainly used for the present field data CRUD operations.
-
gateway: the realization of external dependence Gateway Interface (Domain in the gateway) of.
-
When using COLA, please try to follow standardized components to build our application constraints. This allows our application a clear structure to follow. So it goes, code maintainability and understandability will be greatly improved.
The new extension point design
The introduction of new concepts
Before the discussion, let's define what a new concept introduced in the COLA2.0 expansion design: business, use cases, scenarios.
-
Business (Business): is a self-financing of the financing body, such as tmall, retail and Taobao is through three different business.
-
With Example (Use Case): describes the interaction between the user and the system, each of which provides one or more use case scenarios. For example, the payment order is a typical use case.
-
Scenario (Scenario): scenario is also called an instance of the use case (Instance), it comprises all possible cases embodiment (normal and abnormal). For example, for "order to pay" use case, there "can be used to spend chant," "lack of balance Alipay," "lack of bank account balances" and many other scenes.
Simply put, a plurality of business use cases is composed of a plurality of scenes with the embodiment is composed. A simple example to make use Taobao, business use cases and scenarios in the following relationship:
Implement new extension points
In COLA 2.0, no change in implementation of an extension mechanism, the main change is that the new concepts introduced above. Because COLA extend from design 1.0 star ring, so the size of the original expansion also copy the "business identity" star ring. The method of extended positioning 1.0 COLA shown below:
However, in practice, it can support multiple business scenarios as uncommon as the star ring. More support is differentiated with a different use case scenarios do not use cases, or right. For example, the "Create product" and "product update" are two use cases, but most of the business code can be reused, and only a small part of the need to differentiate treatment.
To support this more fine-grained extended support, in addition to the previous "business identity (BizId)", I also introduced a Use Case Scenario and these two concepts. Positioning a new extension as shown below:
It can be seen in the new extension framework, the original can only support the "business identity" of expansion, now supports the "business identity", "case", "scene" three extensions, will undoubtedly be more flexible than previous and more, and also in the expression of good and understandable than before.
Under the new extension framework, such as the image above we achieve the expansion of the show: In tmall this business - single-use cases - of 88VIP scene - a user identity verification to expand, we only need to declare one of the following the extension implementation (extension) on it.
The new second party library Positioning
About two side surfaces of the positioning library view, it is a simple problem, because the two party libraries and services is nothing less than to expose interfaces and data transfer (DTO). However, to deep thinking, it is not a simple question, as it relates to coordination problems between the different boundary context (Bounded Context). The question of how important it is architecture in distributed environments, different services (SOA, RPC, micro-services, different names, different nature) between collaboration.
Collaboration between Bounded Context
How to enable collaboration between different domains, while also ensuring the integrity of the concept in their respective fields is a set methodology. Overall, there are probably two ways: Sharing the kernel (Shared Kernel) and coating (ACL, Anti-Corruption Layer).
1. Sharing the kernel (Shared Kernel)
It’s possible that only one of the teams will maintain the code, build, and test for what is shared. A Shared Kernel is often very difficult to conceive in the first place, and difficult to maintain, because you must have open communication between teams and constant agreement on what constitutes the model to be shared.
The above is a reference to "DDD Distilled" (The author is Vaughn Vernon) original words on Shared Kernel described, the advantage Share (reduce duplication), its shortcomings are Share (tight coupling between the teams).
2. coating (ACL, Anti-Corruption Layer)
An Anticorruption Layer is the most defensive Context Mapping relationship, where the downstream team creates a translation layer between its Ubiquitous Language (model) and the Ubiquitous Language (model) that is upstream to it.
Also from "DDD Distilled", is to isolate the most thorough coating approach has the advantage that no Share (complete decoupling, each independently), which is no drawback Share (a certain conversion costs).
But my point of view and almost Vernon, are more in favor of the practice of anti-corrosion layer. Because of this increase in semantic conversion Chen, compared to the system maintainability and comprehensibility, it is totally worth it.
Whenever possible, you should try to create an Anticorruption Layer between your downstream model and an upstream integration model, so that you can produce model concepts on your side of the integration that specifically fit your business needs and that keep you completely isolated from foreign concepts.
Repositioning the second party libraries
In most cases, the library is indeed a two-way service is used to define interfaces and data protocols. But the second party different from the JSON library where it is not just the protocol, it is a Java object, a Jar package.
Since it is a Java object, it means that we may make DTO carry more functions in addition to the getter, setter of. This problem did not cause my attention before, but in recent time domain model of thinking, I have found that we can make two party libraries to take on more responsibility, to play a greater role.
In fact, Ali, I found that some teams already in such a practice, and I think the results were pretty good. For example, in the category table second party library, in this matter to do a better demonstration. Merchandise category is more complex logic, which involves a lot of calculations, we look at the code category second party libraries is how to write:
From the above code, we can see that this has gone far beyond the scope of the DTO, this is a Domain Model (has data, behavior, inheritance). The right to do so? I think it is appropriate:
-
First, all data DefaultStdCategoryDO used are self-consistent, that these calculations without the aid of outside assistance, their own to complete. For example, to determine whether it is the root category, whether it is a leaf category, get the name of the path of the category, they are on their own to complete.
-
Secondly, this is a shared kernel, I put myself in the field of knowledge (language, data and behavior) through a two-way exposed to the library, if there are 100 applications that require the use of isRoot () to make a judgment, you do not need to implement the .
what? Not mean that the recommended practice of sharing the kernel it? (Well, children Caifen right or wrong, please). Sharing the kernel here I think is positive, and in particular the categories of data that light, the scene of heavy computing. However, the share caused by tight coupling is indeed a problem. So if I'm a Consumer category of service, I would choose to go with a Wrapper packaging Category multiplexing, so that both can reuse it in the area of capacity, but also can play a role in the isolation of corrosion.
COLA in two-party libraries
Having said that, I think you should have to understand my attitude to the second party libraries. Yes, the two parties should not just be an interface library and DTO, but an important part of the field, is an important means to achieve the Shared Kernel.
Therefore, I intend to expand the scope of responsibilities of second party libraries in COLA 2.0 in. The main points include:
-
second party domain model library is also an important part of the field, a "lightweight" in the field the ability to express, the so-called "lightweight" is that self-expression is appropriate and sufficient cohesion, similar to the above said StdCategoryDO case. Of course, the skills also need to follow the common language (Ubiquitous Language).
-
Collaboration between different Bounded Context, make full use of bridge good second party libraries. Cooperating manner shown below.
Note that this is just a proposal, not a standard. In fact, we always have to make a trade-off between sharing and coupling, there is no perfect world of architecture, there is no perfect design. It fits, you need to own the actual scenes themselves to decide.
COLA framework of the extension mechanism
So far, the alteration point COLA 2.0 I have confessed almost the same. Egg and then append a bar. Leaks about the COLA (Framework) as a framework for how the support extended.
As a component of the framework is to be integrated to complete a specific task in the system, such as a logging framework logback is to help us solve print log, log format, log storage and other issues. But faced with a variety of application scenarios, the framework itself is no way to predict what you want log format, log archiving way. These places need an extension mechanism, enabling users to configure their own, to expand.
For extended to implementation, there are two ways, one is based on the extended interface, the extended one is based on the configuration data.
Based expansion interface
Based on the extended interface is the use of object-oriented polymorphism mechanism, an interface (or abstract methods) in the framework to define the interface and processing templates, then the user to achieve their custom. The principle is as shown below:
This use is widely extended manner in the frame of the ApplicationListener Spring e.g., the user can achieve this special treatment after the initialization container do Listener. Another example of logback AppenderBase, users can customize the Appender demands (to send the log message queue) by inheritance AppenderBase.
COLA as a framework, so scalability is inevitable, for example, we have a ExceptionHandlerI, in the framework we provide a default implementation, as follows:
However, not everyone is willing to apply this arrangement, we offer extended, when the user provides when his ExceptionHandlerI realization of priority that implement user if the user is not provided, the default implementation:
Based on the extended data configuration
Based on the extended configuration data, to agree on a first data format, and then by using the user-supplied data, assembled into an object instance, the data provided by the user is the object attributes (sometimes may be based, for example slfj in StaticLoggerBinder), The principle is as shown below:
We generally disposed KV used in the application are of this form, using the frame are many scenarios, such as the above mentioned logback log format, log size logback.xml configuration.
In COLA, we extended by Annotation points arranged @Extension (bizId = "tmall", useCase = "placeOrder", scenario = "88vip"), is based on a typical extended configuration data.
How to use the COLA 2.0
Source
COLA 2.0 source code https://github.com/alibaba/COLA
COLA application generation
COLA 2.0 provides two sets of Archetype, a pure back-end applications, the other a back-end Web application, the difference between them is the back-end application Web application more than a pure back-end Controller module, the other are the same. Archetype two-party libraries I have uploaded to Maven Repo, the COLA application can be generated by the following command:
Generating pure back-end application (no Controller)
mvnarchetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo -Dversion=1.0.0-SNAPSHOT-Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-service-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT
Generating back-end Web application (there Controller)
mvn archetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo-Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-web-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT
We assume that the new application called demo, then after executing the command, see the following module structure, the application is part of the skeleton, the lower part of the frame is a COLA.
In the application which has some demo generated code can be directly tested using "mvn test". If the back-end Web applications that can run TestApplication start Spring Boot container, and then directly through the REST URL http: // localhost:? 8080 / customer name = Alibaba access services.
COLA 2.0 overall architecture
Finally, according to the old rules, or to two global view of architecture. So that you can grasp the overall situation from the COLA.
Note: COLA has two meanings, one meaning as COLA framework, mainly some applications required to support a common assembly. Another meaning refers COLA architecture refers to the Archetype COLA generated by the application skeleton framework. The architecture here is the view of application architecture view.
Dependent view
Call the view
References:
【1】
https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module?spm=ata.13261165.0.0.12296659zlPIXl
Article from: Ali Technology
