Different people can see the same software project differently. A project manager will see it as a combination of project parameters - budget, deadlines, and amount of work. A business analyst will understand it as a bearer of business value for the users. A database administrator will see it through data - where and what data is saved, in what quality, etc. For a programmer, a project will start to make sense when he understands the technological stack. I could go on, but the matter of the fact is that a software project and software itself exist in several domains at the same time. The analysis of all and their mutual interactions are critical for understanding why one project can succeed, and another one does not. Now, I will take a look at two of them - business and technology.

Perhaps you have experienced it. You sit in a planning meeting where new functionalities are being discussed. The business analyst talks about the fact that we need to add functionality into the system for the import of data from an external system. The software architect thinks for a while and says that we could upload it to a server and then use library XY for it. They both speak about the same. About something new that will be implemented in the system, but each from the perspective of his domain, while they are trying to understand the domain of the other at the same time.

This jumping from one domain to another happens all the time on a software project. If you have ever experienced a misunderstanding between analysts and developers, it was because one or the other side could not understand the perspective of the other. The result may be that something else is programmed than what should have been. One of the reasons why there is a demo ceremony in agile methods is so that both sides can confirm that they understand each other.

Understanding how these two domains coexist on a project is crucial. The main pillar of the technological domain is the so-called technological stack - a list of technologies, platforms, and libraries with their mutual dependencies (for example, the client's application is dependent on the running server). The business domain is often represented by a list of business functionalities, which may also be ordered into a hierarchy, but they may also be independent. Thus, technology may represent the imaginary vertical axis of the software, while business functions may represent its horizontal axis. And now comes the important part: over the course of time, the majority of software grows exponentially more in the business domain (width-wise) than in the technological domain (height-wise). This means that over the course of time, the application will take on more business functionality than new technologies.

This simple fact has an impact on the project. For example, on the artifact structure (documents and files). If you order them based on the business domain, then this system is better scalable (i.e., it can handle further growth) than if you order it based on the technological domain. Good examples are classes in the source code ordered in a certain directory structure. You can select the address structure so that the directories will represent class categories (services, mapping class, data class), and they will contain classes related to various functionality. This is an organization based on the technological domain. Or directories will represent business functionality and contain various types of classes. This is an organization based on the business domain.

Most platforms have gradually switched to organizations based on the business domain because if your application grows in terms of the number of new functionalities, then this solution can be scaled well. If you have it organized based on the technological domain, then it is likely that after some time, you will have a couple of directories with a lot of files - thus, it will be much less transparent. You can consider this organization based on one or the other domain also for testing cases, configurations, documentation, and other artifacts that arise on a project.

In the world of software projects, there has been an effort for some time now to separate these domains from one another and organize them a little bit. A nice effort how to separate the business domain from the technological domain is The Clean Architecture. Here, the domain is represented by the core - a group of classes that contain data and logic that is relevant to this business. Other - external layers - contain more or less only the technological domain. Another example is the Domain-Driven design, which tries to design structures of classes first and foremost from the perspective of the business domain. Neither one of these solutions is perfect, but they both have a chance to contribute better organization and understanding to the project. The Clean Architecture. Doména je tam reprezentovaná jadrom – skupinou tried, ktoré obsahujú dáta aj logiku relevantnú pre biznis. Ďalšie – vonkajšie vrstvy – potom obsahujú viac-menej len technologickú doménu. Ďalším príkladom je Domain-Driven design, ktorý sa snaží navrhovať štruktúry tried v prvom rade z pohľadu biznisovej domény. Ani jedno z tých riešení nie je dokonalé, ale obe majú šancu priniesť lepšie usporiadanie a pochopenie pre projekt.

In conclusion, this is one more story on why understanding the domains of the project is important. A couple of years back, I worked on a project where several developer teams participated in the development of one information system. The company leadership decided to divide this system only from the business perspective. The teams were assigned the implementation of functions in the system irrespective of where these functions were located. The result was that one team had to make changes in different parts of the system - often in several client and server applications at once. Contributions from different teams often had to be integrated on the class level into one application.

The problem is that the lines in the business domain are often in another place than in the technological domain. The system developers understand primarily the technological domain. Therefore, the majority of them did not understand this division because where there was a clear line in the business world, this does not have to be necessarily so in the code. As people who originated from the technological domain, they created a mental model of the system, which was divided based on completely different separation lines. They saw the system as a set of applications (client, server) and not as a set of business functionalities, some of which go through several of these applications. The result was chaos. Chaos, which ended with the fact that after a couple of months, the tasks were redistributed among the teams so that the natural lines of the technological domain - which consist primarily of the individual applications and their interfaces - would be more respected. By this, I don't mean that the division of the development based on business functionalities is not possible. It means rather that it does not have to be as easy as it seems. It is important to recognize that different people on the project come from different domains and thus understand the project differently, and this must be respected. We can talk about the contact and friction points between different roles on the project (project manager, testers, DevOps people) another time.