Pull to refresh

Comments 8

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

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

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

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

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

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

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

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

С появлением 8.х 1С начала укрупнять конфигурации по принципу «все-в-одном». Что это дало пользователям? Повышение производительности труда операторов? Не заметно. Снижение затрат? Наоборот. Упрощение ведения учета? Вряд ли. Я не вижу никаких плюсов для пользователей в укрупненных конфигурациях. Разве что престиж, произведение впечатления.
Спасибо, теперь понятно что вы имели ввиду :)
Описал свою точку зрения на данную проблему отдельной статьёй . В целом солидарен с автором, что в данном случае монолитная система даёт больше преимуществ, чем множество самостоятельных модулей.
Only those users with full accounts are able to leave comments. Log in, please.