Собственно, настоящий текст служит развитием темы про сравнительные достоинства модульных и монолитных систем.
Обучательная практика в очередной раз родила интересный вопрос. «Вот вы почем зря бичуете недостатки модульных систем, а сами продаете компоненты. Собственно, в чем разница?»
Люто, бешено солидаризируясь с Декартом, договоримся сначала о значении слов.
Что такое модуль.
NB: здесь и далее речь идет исключительно в контексте понятийного аппарата ERP-систем.
Итак, «модуль» — функциональность системы, имеющая собственную логику обработки данных и реализующая внутри себя блок бизнес-процессов.
Модуль может быть реализован как отдельным приложением, так и быть частью другого.
Модуль слабо зависим от остальной системы (собственно, совокупности остальных модулей).
Модуль может как иметь отдельное хранилище для данных (необходимость синхронизации с основным хранилищем данных вытекает), так и создавать свои структуры в основном хранилище.
Абстрактным примером возьмем складской модуль.
В нем предполагается наличие некоей логики для хранения данных. В духе того, на какой полке лежит тот или иной товар и т.д.
Следовательно, складскому модулю необходимо иметь вытекающие справочники (полок etc).
Если складской модуль реализован отдельным приложением (исторически, во многих случаях — путем приобретения компании, производившей складской софт), то данные он будет хранить в собственном хранилище, и тем или иным образом реплицировать в основное хранилище.
Впрочем, может и сразу работать с основным хранилищем, это на самом деле не так важно.
Компоненты.
Компонент для платформы Ultima Businessware — отдельное приложение, интегрированное с платформой тем или иным протоколом (REST API, SOAP или собственный, бинарный протокол).
Компонент не хранит первичные данные в своей системе, но всегда передает их в центральную систему. Компонент выступает «витриной данных» или клиентским приложением по отношению к серверу приложений.
Первичные данные — значимые для бизнеса данные, генерируемые пользователями системы (в том числе клиентами через внешние интерфейсы). Например, содержимое товарной накладной, адрес доставки, дата платежки и etc.
Компонент, в отличие от модуля, не имеет собственной бизнес-логики, разделяя реализующий бизнес-логику код (инкапсулированный, как и в любой системе полноценной 3-tier архитектуры, внутри сервера приложений) со всеми остальными частями системы.
Компонент может иметь собственное хранилище данных, но используется оно исключительно для кеширования информации.
Например, движок для создания интернет-магазинов Ultima eStore имеет собственную мини-БД для промежуточного хранения кэша цен, складских остатков и описания товаров. И только.
При регистрации пользователей или создании заказа в мини-БД eStore не остается никаких данных, они транслируются онлайн через сервер приложений в основное хранилище. Поэтому, заметим в скобках, процедура создания клиента при самостоятельной регистрации на сайте или оператором при звонке в колл-центр \ продавцом в магазине абсолютно идентична, разница только в используемом интерфейсе.
Несколько другой вариант использования локального хранилища наблюдается в случае компонента для складской автоматизации Ultima MobileWMS.
Условия эксплуатации требуют максимальной скорости отработки отсканированного штрих-кода — поэтому везде, где это возможно, база данных остатков штрих-кодов загружается в локальное хранилище.
Данные локального хранилища при этом используются исключительно для ответа на вопрос: принадлежит ли отсканированный штрих-код нужному товару, да\нет. За счет кеширования в локальном хранилище можно быстро сообщать о ошибках при наборе. «Правильный» штрих-код отправляется на сервер приложения, дальнейшая обработка идет согласно общей бизнес-логике системы.
А вот компонент для коммивояжера Ultima Door-to-Door или мобильный просмотрщик\подписант Ultima MobileView и вовсе не имеют локального хранилища в ни в каком виде.
Потому что нет надобности: эксплуатационные требования вполне позволяют работать напрямую с центральной БД.
Таким образом, компоненты Ultima Businessware, с одной стороны,
а с другой,
В итоге — существенно упрощается и ускоряется разработка и тестирование. Говоря деньгами — удешевляется поддержка системы в целом, при этом отнюдь не в ущерб качеству.
Формулируя с точки зрения потребителя, компонентный подход позволяет получить все плюсы модулей без их минусов — то бишь, полностью сохраняя монолитность архитектуры в целом.
Обучательная практика в очередной раз родила интересный вопрос. «Вот вы почем зря бичуете недостатки модульных систем, а сами продаете компоненты. Собственно, в чем разница?»
Люто, бешено солидаризируясь с Декартом, договоримся сначала о значении слов.
Что такое модуль.
NB: здесь и далее речь идет исключительно в контексте понятийного аппарата ERP-систем.
Итак, «модуль» — функциональность системы, имеющая собственную логику обработки данных и реализующая внутри себя блок бизнес-процессов.
Модуль может быть реализован как отдельным приложением, так и быть частью другого.
Модуль слабо зависим от остальной системы (собственно, совокупности остальных модулей).
Модуль может как иметь отдельное хранилище для данных (необходимость синхронизации с основным хранилищем данных вытекает), так и создавать свои структуры в основном хранилище.
Абстрактным примером возьмем складской модуль.
В нем предполагается наличие некоей логики для хранения данных. В духе того, на какой полке лежит тот или иной товар и т.д.
Следовательно, складскому модулю необходимо иметь вытекающие справочники (полок etc).
Если складской модуль реализован отдельным приложением (исторически, во многих случаях — путем приобретения компании, производившей складской софт), то данные он будет хранить в собственном хранилище, и тем или иным образом реплицировать в основное хранилище.
Впрочем, может и сразу работать с основным хранилищем, это на самом деле не так важно.
Компоненты.
Компонент для платформы Ultima Businessware — отдельное приложение, интегрированное с платформой тем или иным протоколом (REST API, SOAP или собственный, бинарный протокол).
Компонент не хранит первичные данные в своей системе, но всегда передает их в центральную систему. Компонент выступает «витриной данных» или клиентским приложением по отношению к серверу приложений.
Первичные данные — значимые для бизнеса данные, генерируемые пользователями системы (в том числе клиентами через внешние интерфейсы). Например, содержимое товарной накладной, адрес доставки, дата платежки и etc.
Компонент, в отличие от модуля, не имеет собственной бизнес-логики, разделяя реализующий бизнес-логику код (инкапсулированный, как и в любой системе полноценной 3-tier архитектуры, внутри сервера приложений) со всеми остальными частями системы.
Компонент может иметь собственное хранилище данных, но используется оно исключительно для кеширования информации.
Например, движок для создания интернет-магазинов Ultima eStore имеет собственную мини-БД для промежуточного хранения кэша цен, складских остатков и описания товаров. И только.
При регистрации пользователей или создании заказа в мини-БД eStore не остается никаких данных, они транслируются онлайн через сервер приложений в основное хранилище. Поэтому, заметим в скобках, процедура создания клиента при самостоятельной регистрации на сайте или оператором при звонке в колл-центр \ продавцом в магазине абсолютно идентична, разница только в используемом интерфейсе.
Несколько другой вариант использования локального хранилища наблюдается в случае компонента для складской автоматизации Ultima MobileWMS.
Условия эксплуатации требуют максимальной скорости отработки отсканированного штрих-кода — поэтому везде, где это возможно, база данных остатков штрих-кодов загружается в локальное хранилище.
Данные локального хранилища при этом используются исключительно для ответа на вопрос: принадлежит ли отсканированный штрих-код нужному товару, да\нет. За счет кеширования в локальном хранилище можно быстро сообщать о ошибках при наборе. «Правильный» штрих-код отправляется на сервер приложения, дальнейшая обработка идет согласно общей бизнес-логике системы.
А вот компонент для коммивояжера Ultima Door-to-Door или мобильный просмотрщик\подписант Ultima MobileView и вовсе не имеют локального хранилища в ни в каком виде.
Потому что нет надобности: эксплуатационные требования вполне позволяют работать напрямую с центральной БД.
Таким образом, компоненты Ultima Businessware, с одной стороны,
- позволяют вынести во вне специфический узкопрофессиональный функционал (по большому счету, специальный интерфейс)
а с другой,
- не приводят к печальным последствиям, характерным для классических модульных систем. Описанным, в свою очередь, в статьях, ссылки на которые уже давались выше.
В итоге — существенно упрощается и ускоряется разработка и тестирование. Говоря деньгами — удешевляется поддержка системы в целом, при этом отнюдь не в ущерб качеству.
Формулируя с точки зрения потребителя, компонентный подход позволяет получить все плюсы модулей без их минусов — то бишь, полностью сохраняя монолитность архитектуры в целом.