Continuation of the article “Interaction of links and their isolation.” Part 1

I want to apologize to the public for breaking the article into two parts. But lately, large texts have ceased to be accepted by Habrom. If someone tells you how to deal with this scourge: I will be grateful.

Distribution of roles

It is hard to get rid of old habits, because many teams will have a hard time moving to an isolated approach. For the introduction of an isolated approach, the distribution of roles is well suited. In addition, additional benefits will be obtained from the distribution of roles, including faster and better development.
')
In order to prevent incorrect distribution of work in the links, developers are tied to a specific layer. Work on a specific layer is called a role.

The role of the storage layer

1. Creating views, at the request of the developer in the role of a layer of business logic.
2. Create stored procedures for creating, deleting, and updating data.
3. Processing and optimizing views and SQL in accordance with the optimization plan, index management, etc.

The role of the business logic layer

1. Creation and implementation of external interfaces required for the presentation layer using web services or other means of remoting.
2. Defining the external interfaces used by the presentation layer.
3. Formation of requirements for data presentation and data storage layer stored procedures.
4. The implementation of all data transformations between the virtual and the physical layer.
5. Creation of primary regression tests for building and testing a business logic layer.

Role of the presentation layer

1. UI Implementation
2. Connecting the user interface to the business logic layer using the interfaces provided by the business logic layer role.
3. Development and supply of virtual data sets or other data transfer contract to the business logic layer.

Role transfer

Although developers need to be tied to a specific role, they need to be able to migrate between different roles.

In small teams, transferring roles may allow better allocation of resources. Transferring roles in large teams will allow developers to understand the system as a whole, recognize the impact of their development on the implementation of neighboring links, and protect the system from the influence of an individual developer who has become ill or has left the company.

The transfer of roles, however, should not be carried out as it should and requires control. Developers must assume specific roles at specific times. If possible, the developer should not assume more than one role within the same module. If there is a “Buyer” module in the system, each developer should not be assigned more than one role within the “Buyer” module. However, if the developer works on the business logic layer in the Buyer module, and then switches to the development of the presentation layer in the Supplier module, this is acceptable and allows for more efficient allocation of resources.

The following figure shows an example of the correct allocation of roles.



The following figure shows the wrong distribution of roles. Both Joe and Adam work in different roles within the same module. Such violations lead to a close connection and loss of isolation between the layers.



The previous example is very simple to describe and uses only one developer per module and link. However, such a case is quite rare, and in reality many developers distribute the load. However, as long as none of the developers move between links within the same module, the principle is observed.



In these examples, Petya deals exclusively with the development of the data storage layer. This is not mandatory, and in reality Petya can work on other layers. Other developers can also work on the data storage layer. But usually DBA and only DBA deal with the data storage layer, that's what I depicted.

Small teams

In small teams, assigning one role to one developer will result in a lack of resources. In small teams, developers should change roles with greater frequency, since the role may go to sleep when the necessary elements are completed. Although the change of roles occurs more frequently, it must, nevertheless, be controlled. A role change must be clear and made only when there is no work in the role being abandoned.

Ultra small teams and loners

Ultra-small teams and singles have no choice but to work in different roles within the same module. Developers are required to stay within the layer and make clear movements between them.

A typical method is to complete one module and go to the next one when the previous one is completed. Assume the following approach:


However, the developer will make 2/3 movements in horizontal. If something went wrong, the tendency to take a step back will prevail, create a compromise solution and return:


It may be useful to complete layer by layer, rather than module by module. So we isolate the layers from each other. Such an approach, however, is not always possible and requires completion of the design in advance. In addition, some developers may find it inconvenient and difficult to jump between modules, rather than move sequentially through layers:


Please note that with this approach only two horizontal steps occur:


If you use the described approach, instead of moving between layers, do not forget to move between modules as well. The following figure shows the best way: