Pull to refresh
0

Чем отличается ворона от письменного стола Или разница между «ихними» модулями и «нашими» компонентами

Reading time 3 min
Views 6.3K
Собственно, настоящий текст служит развитием темы про сравнительные достоинства модульных и монолитных систем.

Обучательная практика в очередной раз родила интересный вопрос. «Вот вы почем зря бичуете недостатки модульных систем, а сами продаете компоненты. Собственно, в чем разница?»

Люто, бешено солидаризируясь с Декартом, договоримся сначала о значении слов.

Что такое модуль.
NB: здесь и далее речь идет исключительно в контексте понятийного аппарата ERP-систем.

Итак, «модуль» — функциональность системы, имеющая собственную логику обработки данных и реализующая внутри себя блок бизнес-процессов.

Модуль может быть реализован как отдельным приложением, так и быть частью другого.

Модуль слабо зависим от остальной системы (собственно, совокупности остальных модулей).

Модуль может как иметь отдельное хранилище для данных (необходимость синхронизации с основным хранилищем данных вытекает), так и создавать свои структуры в основном хранилище.

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

Компоненты.
Компонент для платформы Ultima Businessware — отдельное приложение, интегрированное с платформой тем или иным протоколом (REST API, SOAP или собственный, бинарный протокол).

Компонент не хранит первичные данные в своей системе, но всегда передает их в центральную систему. Компонент выступает «витриной данных» или клиентским приложением по отношению к серверу приложений.

Первичные данные — значимые для бизнеса данные, генерируемые пользователями системы (в том числе клиентами через внешние интерфейсы). Например, содержимое товарной накладной, адрес доставки, дата платежки и etc.

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

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

Например, движок для создания интернет-магазинов Ultima eStore имеет собственную мини-БД для промежуточного хранения кэша цен, складских остатков и описания товаров. И только.
При регистрации пользователей или создании заказа в мини-БД eStore не остается никаких данных, они транслируются онлайн через сервер приложений в основное хранилище. Поэтому, заметим в скобках, процедура создания клиента при самостоятельной регистрации на сайте или оператором при звонке в колл-центр \ продавцом в магазине абсолютно идентична, разница только в используемом интерфейсе.

Несколько другой вариант использования локального хранилища наблюдается в случае компонента для складской автоматизации Ultima MobileWMS.

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

Данные локального хранилища при этом используются исключительно для ответа на вопрос: принадлежит ли отсканированный штрих-код нужному товару, да\нет. За счет кеширования в локальном хранилище можно быстро сообщать о ошибках при наборе. «Правильный» штрих-код отправляется на сервер приложения, дальнейшая обработка идет согласно общей бизнес-логике системы.

А вот компонент для коммивояжера Ultima Door-to-Door или мобильный просмотрщик\подписант Ultima MobileView и вовсе не имеют локального хранилища в ни в каком виде.
Потому что нет надобности: эксплуатационные требования вполне позволяют работать напрямую с центральной БД.

Таким образом, компоненты Ultima Businessware, с одной стороны,
  • позволяют вынести во вне специфический узкопрофессиональный функционал (по большому счету, специальный интерфейс)

а с другой,
  • не приводят к печальным последствиям, характерным для классических модульных систем. Описанным, в свою очередь, в статьях, ссылки на которые уже давались выше.


В итоге — существенно упрощается и ускоряется разработка и тестирование. Говоря деньгами — удешевляется поддержка системы в целом, при этом отнюдь не в ущерб качеству.

Формулируя с точки зрения потребителя, компонентный подход позволяет получить все плюсы модулей без их минусов — то бишь, полностью сохраняя монолитность архитектуры в целом.
Tags:
Hubs:
0
Comments 0
Comments Leave a comment

Articles

Information

Website
www.ultimaerp.com
Registered
Founded
Employees
51–100 employees
Location
Россия