Монолит или кирпич?

    Сегодня немного философии про архитектуру программных систем — монолитной или модульной. Когда и какая модульность полезна, всегда ли она благо или нет. Ну и более предметно про ERP системы как близкая нам тема.


    Определения.

    Прежде чем раздувать пламя споров, необходимо договориться о дефинициях.

    Монолитная система — программный комплекс, который работоспособен только в своей единственной конфигурации и объеме программного кода. Модульная система — программный комплекс состоящий из независимых самодостаточных программных систем.

    Определение немного отдает тавтологией, но и провести предельно четкую границу между модульными и монолитными системами невозможно. Хотя бы потому, что и понятие программного комплекса не имеет четкого определения. Если говорить терминами нечеткой логики, то вероятность, что система монолитна, растет с уменьшением числа внешних интерфейсов модулей и обращений к любым внешним системам. В свою очередь, система более модульная чем большее число интерфейсов присутствует в системе.

    Монолитные системы так же отличаются изолированностью — данные модулей доступны только модулям-владельцам, остальные модули получают информацию через внешние интерфейсы. В случае с ERP системами это означает разделение данных модулей вплоть до различных СУБД для каждого модуля.

    Разобравшись с определениями переходим к тезисам.
    • Плюсом модульной системы считается возможность наращивать функционал системы добавлением новых модулей.
      Что это означает на самом деле? Что получатель системы получает систему частями.

      Возможно, в начале истории компьютерной техники и были проблемы с размещением всей программы на оборудовании, но такие проблемы исчезли как класс. И сейчас нет никакой проблемы разместить весь программный комплекс на оборудовании. Преимущества поставки системы модулями очевидны для продавца, и совершенно не очевидны для покупателя. Впрочем это несколько отдельная тема, за ней отсылаю к нашей статье.
    • •Модульные системы легко поддерживать. На самом деле в модульной системе легко создавать новые модули. Однако модульные системы пасуют, когда требуется значительное изменение функционала двух или более взаимодействующих модулей. Слабая связность становится проблемой не позволяющей тестировать на этапе компиляции.

    В реалиях ERP систем имеем как раз такой образчик — меняется функционал существующих, интенсивно взаимодействующих подсистем. Стоимость нарушения взаимодействия крайне высока.

    ERP системы, одни из самых сложных программных систем, созданных человечеством (еще операционки, игры, гугл и фейсбук) имеют потребность меняться вместе с изменением бизнес-процессов, что заставляет их меняться быстрее чем прочие программные системы. Именно поэтому, модульные системы начинают сильно страдать от накапливающихся изменений в протоколах обмена из-за отсутствия формальных механизмов контроля качества.

    Подводя итог, имеем — модульные системы отличное архитектурное решение для стабилизированного приложения, в стабильном окружении, где требуется только увеличение функционала системы, в виде создания НОВЫХ функций.

    Более-менее современные, реально используемые системы (созданные после 1995-го года) имеют монолитную архитектуру, или тяготеют к монолитной архитектуре.

    Модульную архитектуру имеют либо системы, носящие экспериментальный характер, либо системы, которые получили модульную архитектуру в итоге череды поглощений и преобразовании купленных программных систем в “модули” системы. Такие системы, в итоге, имеют весьма изощренный функционал обмена сообщения, преобразования интерфейсов и прочих механизмов реализации взаимодействия между модулями. По нашему опыту сложность растет очень быстро с ростом числа модулей.

    Не так давно один из коллег в статье сетовал на отсутствие модульности в 1С. Не думаю что разработчики 1С порадовались бы обилию всевозможных проверок о наличии того или иного модуля. Порадовались бы только компании, поддерживающие 1С что теперь надо настраивать не одну программу, а сразу несколько модулей, да еще и некий middle-ware их интеграции.

    Перейдем к особенностям модульных ERP-систем где модулями являются бухгалтерия, склад, управление финансами, сотрудниками и т.п.

    Как минимум, ERP система должна отражать реальное положение дел в компании. Например — сколько товара лежит на складе. Или сколько денег на расчетном счете. Модульная система ввиду слабо-связанности и изолированности модулей быстро скатывается к дублированию информации. И далее к расхождению показателей.

    Например — складской модуль списывает 10 штук товара со склада. Финансовый модуль должен списать их стоимость своей отдельной операцией. Однако, в процессе работы, возникают вроде незначительные события — отказ канала, изменение в протоколе обмена. По прошествии некоторого времени оказывается, что товара на складе нет — ноль штук, а в данных финансового модуля этого товара на складе лежит на сто рублей. В итоге, появляется специальная коррекция в финансовом модуле, и далее, такие ошибки распространяются по системе. В монолитных системах списание со склада — единая операция (в нашем случае — единая запись) о движении денег и единиц товара, что значительно повышает достоверность данных.

    Данные монолитных систем лежат в единой базе данных, для них выполняются все правила ссылочной целостности, а изменение структуры данных едино для всей системы. Поэтому вероятность искажения данных значительно снижается, не говоря уже появлении нескольких вариантов реальности.

    В заключение.

    Среди разработчиков (как впрочем и среди любых людей и даже у птиц существует много иррациональных предубеждений. Среди них — об архитектуре программных систем, что модульность и слабо-связанность лучше монолитности. Как сущность.

    P.S. Если кому интересно, критический взгляд на проблематику модульности с точки зрения эксплуатанта.
    Ultima
    43,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 8

      0
      С другой стороны, монолит приведёт к базе на полтерабайта.
      Когда-нибудь один сервер перестанет тянуть всю систему, каким бы он ни был мощным. Придётся откалывать куски и выносить на другие сервера, выполнять что-то асинхронно через очереди.
        0
        Позволю не согласиться.
        В реальных проектах размеры баз составляют терабайты (в одном проекте скоро начнем считать десятками).
        Один сервер конечно когда-то перестанет тянуть, поэтому современные СУБД имеют функции кластеризации (у Oracle — Real Application Cluster). Надо понимать, что этот кластер с точки зрения сервера приложений — все так же одна база. Кроме того, благодаря логарифмической сложности поиска скорость падает медленно. Упрощая, но по сути верно — для поиска среди 4 000 000 000 (4-х миллиардов) записей надо сделать 32 чтения, а среди 8 000 000 000 (8-ми миллиардов) требуется 33, для 16 — 34. Кроме того, у баз данных есть и другие технологии, которые упрощают работу с большими таблицами.
          0
          Хорошо, если сразу проект построен на масштабируемом сервере. У меня в примере firebird. Мигрировать на другую СУБД нереально, кластер он не поддерживает. Если бы не ограничения СУБД, монолит был бы отличным решением.
        0
        Данные монолитных систем лежат в единой базе данных

        А данные модульных систем обязаны лежать в разных бд? Даже если так, что мешает настроить репликацию?

        Модульная система — программный комплекс состоящий из независимых самодостаточных программных систем.

        Однако в вашем примере складской и финансовый модуль — не такие уж независимые, т.к. операция списания со склада должна проводиться в рамках единой транзакции. Получается, что складской модуль не может самодостаточно и независимо выполнить операцию списания, опираясь только на нижележащие слои ПО. Думаю, тут можно вынести корень аггрегации и операцию списания в общую библиотикеку (или, если операция списания не слишком сложна, в хранимую процедуру в бд), вызываемую по-необходимости из одного из модулей. Если в терминах предметной области списание — единая неделимая операция, то в коде она должна быть представлена в виде отдельной сущности.
          0
          Модульные системы не обязанны лежать в разных бд. Но по факту так и есть, во много исходя из истории их возникновения, я в статье решил не углублятся. В статье на нашем сайте чуть подробнее про это есть.

          По второму. Я там ведь дальше написал что нельзя так формально подходить к этому определению. В приведенном Вами примере складской модуль самодостаточен с точки зрения сотрудников склада, ибо покрывает все их потребности.

          Если Вы будете отталкиваться от требований предметной области и разрабатывать систему с нуля, то у вас для ERP систем как раз и получится скорее монолитная система, ибо там все утыкано «единая и неделимая операция». А если будете отталкиваться от того, что есть, то модульная.

          Главное в данном случае — не приносить бизнес-требования в жертву неким архитектурным догмам, что часто встречается.
            0
            Единственная и неделимая операция — это подпись на бумажном документе. А в той же складской операции может отражаться несколько бумаг, причем не обязательно единых во времени подписания. Сам факт двойственности бумажного и электронного учета уже ставит хер (который буква Х) на единственности и неделимости.

            Касаемо 1С. На 7.7 были десятки конфигураций под все виды учета. Если фирма крупная (холдинг, например), то использовались десятки и сотни экземпляров баз данных под разные юр.лица и виды учета. Для аналитики и отчетности данные выгружались или выдергивались напрямую из баз. И это вполне работало, и не особо напрягало, потому как большинство простых конфигураций не требовало доработок, а которые требовали — хватало усилий одного разработчика.

            С появлением 8.х 1С начала укрупнять конфигурации по принципу «все-в-одном». Что это дало пользователям? Повышение производительности труда операторов? Не заметно. Снижение затрат? Наоборот. Упрощение ведения учета? Вряд ли. Я не вижу никаких плюсов для пользователей в укрупненных конфигурациях. Разве что престиж, произведение впечатления.
          0
          Спасибо, теперь понятно что вы имели ввиду :)
            0
            Описал свою точку зрения на данную проблему отдельной статьёй . В целом солидарен с автором, что в данном случае монолитная система даёт больше преимуществ, чем множество самостоятельных модулей.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое