A, the opening

When we learn new technologies or solve some business and technical problems, many students will concentrate on details and think about how to solve them quickly, forming a point-like knowledge structure and cognitive system over time. As I often do when interviewing middle and advanced programmers, I often ask the question: what is Java’s body of knowledge/what is Java’s composition? And as one might expect, there were often candidates who were confused, to quote one of my high school class teachers, “blank-blanking.” So we come to the conclusion that systematic thinking and learning is so important that today’s impetuous society and climate make those who can sink down the programmer practically have fewer competitors.

Two, return to the theme

Let’s return to the topic of this time and first understand the role of application architecture diagrams: they are used to describe the application architecture, specifically the composition and framework of the system. This explanation is both clear and abstract. In this article, we will focus on the application dimension to understand how to build our application architecture diagram, what is an application architecture diagram, and what exactly is an application?

Baidu encyclopedia is given a lot of kinds of interpretation, in numerous explanations, I give to the more enlightening role is a set of digital bloom information tools here, creating six levels according to the cognitive domain, memorization, comprehend, application, analysis, evaluation and creation, the interlocking between each other, restrict each other and interdependent. In these six levels, application can be said to have a core position, a link between the preceding and the following and the final value presentation.

Apart from digital bloom the interpretation of the theory itself, we can understand so, for an enterprise to carry out production activities in the use of certain areas, we’ve learned through the analysis and evaluation of the field into the role of the market and produce the value of the final decision whether to need through the innovation of the enterprise means further excavate its greater value and then bring the cycle of higher value, If a more official or abstract language is for the enterprise, decided to enterprise’s development strategic direction and business enterprise management mode, for a system to decide how much the value of the system, the user’s evaluation is good in the future will also need the system to a wider range of promotion and even expand, it is up.

Downward effect, we understand only after memorization, understanding, it is possible to enter the application level. Memorization is a psychological word, it is an important relief of memory, through the process of repeated perception, after reaching the memory conditions, began to understand, that is, to appreciate the truth contained in the affairs and have a deep experience of it. So what we remember, what we perceive and what we perceive becomes more important, and it’s not hard to imagine that for a system it all depends on the context in which the system is being used, and it all boils down to application.

Let’s take a look at the solution of Baidu Encyclopedia for application architecture:

Application Architecture is the content that describes the functionality and technical implementation of AN IT system. Application architecture can be divided into the following two layers: enterprise level application architecture and individual system application architecture……

No matter the application architecture of enterprise level or a single system, it is finally explained from two dimensions of system function and technology. This time there will be some confusion, we are learning or draw business architecture or even product architecture diagram, also can appear an overview of system function sexual content, that is to say, whether in the system function as the core application architecture, or in the business architecture will appear with the function of the business language description, such as financial management, marketing management, These simplified function description phrases can be found in both application architecture and business architecture. For students who are new to architecture and start to draw their own architecture, it is inevitable that they will draw a picture of four different things, and even when they finish drawing their own architecture, they will be asked, “What kind of architecture diagram is this diagram?” So I was thinking that drawing a business architecture is no longer a real business architecture, so how do you really differentiate between different architectures?

What we programmers often call system architecture, or enterprise architecture, TOGAF describes as follows:

• Business Architecture: Defines business strategy, governance, organization, and key business processes
• Application architecture: Describes the structure and interactions between applications
• Data architecture: Describes the structure of an organization’s logical and physical data assets and data management resources
• Technology architecture: Describes the software and hardware capabilities, including IT infrastructure, middleware, networking, communications, processing, and standards, that support the logic required for the deployment of business, data, and application services

After a series of descriptions of TOGAF, the question seems to arise again, what is the difference between technology architecture and technology-centric application architecture?

All the questions and answers come down to two words: domain.

We have always been revered or yearning for DDD field driven programming, seemingly lofty, but in fact, in the absolute majority of companies is not really implemented, the reason seems to be the use of DDD mode for development, the whole development work has become huge, the work may more than double the increase. Often the business evolves so fast, the business changes and changes so frequently and unreasonably, that software companies end up thinking DDD is a good thing from top to bottom, but it can’t be implemented. Personally think deep reason or understanding of field and a lot of misunderstanding, and even don’t understand, and ignorance leads to disagree, we often say that business and technology to have a common language, through the domain model that transactions between business and technology to achieve cognitive consistency, yes, we still cannot execute truth is very simple. In DDD domain-driven programming, where all the core focus is really on the domain model, a relatively stable and well-developed domain model is so important (at least for some time to come), especially for DDD, In terms of reality, if the business itself cannot be stabilized or the predictable time of an enterprise, a product or a project in the future can not be predicted through discussion, how can a stable domain model and DDD be implemented? Business and products are usually designed in this way for the time being, and they can be changed in the future when problems arise. Of course, the technology duration is also the same. However, the influence brought by the temporary design of technology will not affect the business and products in return from the implementation of DDD.

Whether it is the confusion of various architecture diagrams or the simple analysis of DDD that can not really be implemented, the fundamental reason is the fuzzy concept of the domain and the neglect of the domain in the process of software design and development. We can reflect on, in their past programming experience, how much is to pay attention to the field, that does not pay attention to the embodiment is to do after receiving the demand, the better to do a technical solution and then open, the demand has changed to change the technical solution and finally change the code.

In my impression in this respect we have worship of companies do really good, now slowly many benefits of good enterprise also began to pay attention to the design of area, this design is not just technology, is designed to the business and products, certainty and uncertainty affected area boundary is not only a technical team, and even the entire enterprise’s organizational structure will have a far-reaching impact.

Third, summary

The paper come zhongjue shallow, and must know this to practice. When we draw application architecture diagrams or other system architecture diagrams, we must first understand what the domain boundaries of each architecture diagram are and what business scenarios and problems it is intended to solve, otherwise the situation will be inconsistent. So we need to know what is going on in the domain, domain modeling, domain driving, this is another topic worth learning, thinking about, discussing and actually landing.

Back to our question, do you know how to draw an application architecture diagram?

• Step 1: Understand the boundaries of various system architecture diagrams by domain boundaries.
• Step 2: Do you really want to spend the application architecture diagram? Whether to draw the application architecture diagram with system function as the core or the application architecture diagram with technology as the core.
• The third step: define the boundary and definition of each system or function, the correlation between systems and constraints, what to rely on below, what to use for whom to achieve what effect.