Architecture Ramble: How to write code from an architectural perspective

Transferred from: http://kb.cnblogs.com/page/542725/

In the sixth article, we come to the conclusion that the software architecture actually includes: The code architecture, and the hardware deployment architecture that hosts the code. In fact, the hardware deployment architecture is ultimately determined by the architecture of the code. Because the code schema is unreasonable, it is impossible to separate a running unit from multiple, then the hardware architecture can be separated very limited, the whole system ultimately difficult to grow larger.

So we often hear, rewrite the code, overturn the original architecture, redesign and so on, to illustrate the evolution of the architecture. This is actually the result of not having enough thought to complete the task. This is not a matter of architectural evolution, but rather a process of personal understanding of the problem domain. So it's important to discuss what the code should look like.

This article will be based on a few previous articles, and further explore how to put the architectural thinking to the ground, refined into our code practice, try not to let the code become the bottleneck of system growth, reduce the cost of the architecture split.

As we mentioned earlier, software is actually a simulation of real life, virtualization . This is a very important premise that directly determines that our code should be divided into several parts. Combining the responsibilities of each deployment unit can be clearly split into two different responsibilities:

1. The code that expresses the business logic. Many people call this part domain Logic, or domain Model. This part actually originates from the life, must maintain and the real life the segmentation consistent, is not artificial abstraction.

2. The code that provides access to the user and saves the result of running the business logic. There is a flaw in the state of the computer, this machine retains the result of business operation is very big problem, generally is stored on the external storage device, but also easy to expand.

So the code for a single deployment unit can be divided into two parts, as shown in:

Architecture Ramble: How to write code from an architectural perspective