{"id":409,"date":"2025-05-19T21:08:50","date_gmt":"2025-05-19T19:08:50","guid":{"rendered":"https:\/\/spireng.sk\/?p=409"},"modified":"2025-05-19T21:08:50","modified_gmt":"2025-05-19T19:08:50","slug":"modularita-alebo-ako-spravne-narezat-softver","status":"publish","type":"post","link":"https:\/\/spireng.sk\/en\/modularita-alebo-ako-spravne-narezat-softver\/","title":{"rendered":"Modularity or How to Properly Split Software"},"content":{"rendered":"<p>Divide and conquer is a famous phrase from antiquity that describes how to manage your enemies, but it is also the name of an algorithm to solve problems. The same phrase can be used to split the software into smaller parts, i.e., its modularization. The fact that, at some point, you have to start splitting the software solution into smaller parts is a fundamental fact of its development. However, what is not clear is how to split it properly. Often, it is a division by the structure of the organization, which is developing the software (so-called Conway law), or the application is split so that its structure would be easily understandable. Although this might seem like a good approach, some advantages of modularization get lost because of this. Let\u2019s take a look at how this can be done better.<\/p>\n\n\n\n<p>Properly splitting software is a science, and several aspects are included in this. The most commonly used are the borders in the business and the technology domain (see my article on the domains of a software project). Take a microservice, which contains one central object (user, invoice, document) and a collection of objects that amend it. You are getting a component that has clear, and for us, natural borders in the technological and business domain. This division is common because, inter alia, it introduces an easier understanding and development.<\/p>\n\n\n\n<p>In addition to this approach, there are other aspects which should be considered. When splitting software, you should think about at least these other criteria:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Administration<\/li>\n\n\n\n<li>Security<\/li>\n\n\n\n<li>Potential of changes<\/li>\n<\/ul>\n\n\n\n<p>Let\u2019s discuss them one by one.<\/p>\n\n\n\n<p><strong>Administration<\/strong><\/p>\n\n\n\n<p>Probably the most important aspect of modularization. For starters, let\u2019s take a look at a couple of examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You have developed a server component that contains two critical processes. You need both of them to have as little outage time as possible. But one of them ends with an error, and it stops.  You would need to restart this component, but this would also mean the outage of the second critical process, which you do not want.<\/li>\n\n\n\n<li>In another case, you have developed a component that contains a critical process. Additionally, it contains a number of less important processes. Since all processes share the same resources as the operating system, you cannot properly monitor and scale one critical process. Additionally, when you increase their number, these resources are also consumed by other processes.<\/li>\n<\/ul>\n\n\n\n<p>In both cases, it is the same problem - a critical process is packed in one component together with something else, which makes its management more difficult. The basic idea when considering the administration under modularization is that the processes, which are critical (it is important for them to run steadily, constantly or they work with a large set of data) are separated.<\/p>\n\n\n\n<p>There is nothing worse for administrators than when they get a poorly modularized application. The critical processes and their data are mixed with other, less important ones. They share the same system resources. Thus, it is not possible to prioritize and individually manage them. On the other hand, the solution is not to completely disintegrate the system. If there are too many components, then it introduces too much unnecessary work and micromanagement. Therefore, it is important to find the right granularity and separate the most important parts within its scope.<\/p>\n\n\n\n<p><strong>Security<\/strong><\/p>\n\n\n\n<p>Security is another domain through which you can look at the software project. In principle, this domain consists of actions or data that you want to protect, vectors of possible attack, and protection (i.e., prevention of attack). The fact is that not all data and actions in your system have the same importance from a security perspective. There are certain borders in this domain as well, and modularization should respect them as well. Otherwise, it may happen that higher security is also applied to those parts of the system - processes, and data - which do not require it, only because they are part of the component of the process, which is critical from the security perspective. And security - irrespective of how much it is necessary - is not free. Both in development and in operation.<\/p>\n\n\n\n<p><strong>Potential of changes<\/strong><\/p>\n\n\n\n<p>I have personally never encountered software that would be used for years after it was created, and it would not be necessary to make regular changes to it. The more extensive and important the system, the higher the chance of additional changes. Changes, in general, should be as small as possible. The bigger the change in the system, the more expensive and risky it is. As the saying goes, there is no small change in complex systems. Therefore, it is advisable to design an application in which parts of the system that have great change potential are separated.<\/p>\n\n\n\n<p>But how to know what will be changed? At first glance, it might look like a difficult question. At first glance, this might not be as complex. First and foremost, it is necessary to look at the software from the perspective of different domains (business, technology, security, \u2026). Changes have happened in the past in all of them. In each of them, there is a competition or an alternative, which is different in some aspects. All of these are points of potential change. These parts - the parts with a great change potential - should be separated during modularization. The result might be that the change will be isolated only in one component as opposed to a situation where it would impact a big part of the system.<\/p>","protected":false},"excerpt":{"rendered":"<p>Divide and Conquer je zn\u00e1ma fr\u00e1za z&nbsp;antiky ako zvl\u00e1da\u0165 nepriate\u013eov, ale aj n\u00e1zov algoritmu na rie\u0161enie probl\u00e9mov. Rovnak\u00e1 fr\u00e1za sa d\u00e1 pou\u017ei\u0165 aj na delenie softv\u00e9ru na men\u0161ie \u010dasti, teda jeho modulariz\u00e1ciu. To, \u017ee softv\u00e9rov\u00e9 rie\u0161enie mus\u00edte v&nbsp;nejakom momente za\u010da\u0165 deli\u0165 na men\u0161ie \u010dasti, je z\u00e1kladn\u00fd fakt v\u00fdvoja. \u010co ale nie je tak jasn\u00e9 je [&hellip;]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-409","post","type-post","status-publish","format-standard","hentry","category-vyvoj-softveru"],"_links":{"self":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts\/409","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/comments?post=409"}],"version-history":[{"count":1,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts\/409\/revisions"}],"predecessor-version":[{"id":410,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts\/409\/revisions\/410"}],"wp:attachment":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/media?parent=409"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/categories?post=409"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/tags?post=409"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}