Low Blood Application Architecture

Little sketch on how to develop a high-level application architecture.

Suppose that you have decided on future functionality. Then you know exactly who or what will supply the data, who / what will consume it and what data conversion the system itself should perform.

Take a piece of paper and a pencil. If you are not very confident in your abilities, then also a rubber band to rule the scheme. More advanced readers can turn to professional tools for designing architecture in electronic form.
')
Now find out who will access your system to transfer or collect data, and what your program will address. Those systems or users who access the program themselves, sketch out on a piece of paper at the top. Those that will be addressed by the program (including the database) are from below.

Now draw a rectangle with the name of the UI or API under each top drawn subject — these are the interfaces that the user or the external control system will access. Sometimes the UI can also access the API. Merge all the rectangles with a single contour UI and circle the presentation layer. Merge all the rectangles with the API and layer around the services.

For the systems drawn below, specify the components that will be responsible for access to these systems. Combine all of these components into a single circuit and circle the data access layer.

Between the services layer and the data access layer, draw a large outline and name it a layer of business logic. In the small boxes inside this outline, list the main business tasks. One component of your system will solve one business problem.

Now, on the right, draw several long rectangles from top to bottom and write in them: logging, configuration, performance monitoring, exception handling and something else that is a common infrastructure (or end-to-end functionality) for all layers of your program.

You have received the logical architecture of the application. Scatter layers across servers — get a physical architecture.

Now you need to work out every little square in detail.

I'll put a little practical example under cat.

For example, I will take a completely virtual project of the secondary school grade control system. Take it for two reasons. First, we all went to school. Secondly, many of us children are now studying in the same school. Because of this, I hope the subject area will be clear to everyone.

So, our system will be designed for keeping electronic diaries of students and electronic classroom journals. In the appendage, let the system have some additional set of functions, allowing students, parents and teachers to exchange messages, and school management to control the learning process.

So, the users of our system will be students, their parents, teachers and school management. In addition, users will be system administrators who need to receive information about events in the system and perform some service operations. We will not list the use cases, not about them.

Users will interact with our system either through a web interface or using a mobile application. Both user interfaces are designed for schools that cannot afford to develop their own website. The rest will be able to access our system through web-services.

There will be four services: an electronic diary, an electronic journal, organization of the educational process and administration.

Under the layer of services will be a layer of business logic, consisting of a dozen components that solve the business problems of users.

The data will be stored in a database. And there will be two bases: combat and archival.

The system will export / import data from files. In addition, there will be two external systems to which our system will connect remotely: the reference information system and the information system of the Department of Education.

End-to-end functionality will make up the mechanisms of logging, monitoring, configuration management, security.

As a result, we get just such a simple scheme:



Now you can select the physical nodes. Web user interface and services will be deployed in a web cluster. Layers of business logic and data access will be implemented on the application server. Databases will be located in a separate failover cluster. Later it will be possible to depict all the nodes in the form of a beautiful scheme of physical architecture.

I hope the example is clear.

In order to dive deeper into the topic, I suggest you pay attention to the Microsoft Application Design Guide . The manual is written in the form of a reference book, so you can quickly find recommendations for designing each layer of the system.