Собственно, этот текст служит развитием темы о сравнительные преимущества модульных и монолитных систем .
Образовательная практика в очередной раз поставила интересный вопрос.
«Что ты делаешь зря? критиковать недостатки модульных систем , и себя продавать компоненты .
Собственно, какая разницаЭ» Яростно, в яростном солидарнии с Декартом, давайте сначала договоримся о значении слов.
Что такое модуль? NB: здесь и далее мы говорим исключительно в контексте понятийного аппарата ERP-систем.
Итак, «модуль» — это функционал системы, имеющий собственную логику обработки данных и реализующий внутри себя блок бизнес-процессов.
Модуль может быть реализован как отдельное приложение или быть частью другого.
Модуль слабо зависит от остальной части системы (фактически от совокупности других модулей).
Модуль может либо иметь отдельное хранилище для данных (отсюда необходимость синхронизации с основным хранилищем данных), либо создавать свои структуры в основном хранилище.
Давайте возьмем складской модуль в качестве абстрактного примера.
Предполагается наличие некоторой логики хранения данных.
В духе того, на какой полке стоит тот или иной товар и т.д. Поэтому складской модуль должен иметь плавные каталоги (полки и т. д.).
Если модуль хранилища реализован как отдельное приложение (исторически во многих случаях путем приобретения компании-производителя складского ПО), то он будет хранить данные в собственном хранилище и тем или иным образом реплицировать их на основное хранилище.
Однако он может сразу работать с основным хранилищем; на самом деле это не так важно.
Компоненты.
Компонент для Платформы Ultima Businessware — отдельное приложение, интегрированное с платформой по тому или иному протоколу (REST API, SOAP или собственный бинарный протокол).
Компонент не хранит первичные данные в своей системе, а всегда передает их в центральную систему .
Компонент действует как «киоск данных» или клиентское приложение по отношению к серверу приложений.
Первичные данные — это важные для бизнеса данные, генерируемые пользователями системы (включая клиентов через внешние интерфейсы).
Например, содержание накладной, адрес доставки, дата платежа и т. д. Компонент, в отличие от модуля, не имеет собственной бизнес-логики , разделяя код, реализующий бизнес-логику (инкапсулированную, как в любой системе полноценной 3-х уровневой архитектуры, внутри сервера приложений) со всеми остальными частями системы.
Компонент Может быть имеют собственное хранилище данных, но используется оно исключительно для кэширования информации.
Например, движок для создания интернет-магазинов Ultima eStore имеет собственную мини-базу для промежуточного хранения кэша цен, складских остатков и описаний товаров.
Но только.
При регистрации пользователей или создании заказа в мини-БД интернет-магазина не остается данных; он передается онлайн через сервер приложений в основное хранилище.
Поэтому отметим в скобках, что процедура создания клиента при регистрации самостоятельно на сайте или оператором при звонке в колл-центр/продавцом в магазине абсолютно идентична, разница лишь в используемом интерфейсе.
Немного другой вариант использования локального хранилища наблюдается в случае компонент для автоматизации склада Ultima MobileWMS .
Условия эксплуатации требуют максимальной скорости обработки отсканированного штрих-кода – поэтому, где это возможно, база данных остатков штрих-кодов загружается в локальное хранилище.
Данные локального хранилища используются исключительно для ответа на вопрос: принадлежит ли отсканированный штрих-код нужному товару, да/нет. Кэширование в локальном хранилище позволяет быстро сообщать об ошибках ввода.
«Правильный» штрих-код отправляется на сервер приложений, и дальнейшая обработка происходит в соответствии с общей бизнес-логикой системы.
И здесь компонент для коммивояжера Ultima Door-to-Door или мобильный просмотрщик\подписчик Ultima MobileView и не имеют локального хранилища в любой форме.
Потому что в этом нет необходимости: эксплуатационные требования полностью позволяют работать напрямую с центральной базой данных.
Таким образом, компоненты Ultima Businessware, с одной стороны,
- позволяют реализовать конкретный, высокопрофессиональный функционал (по большому счету специальный интерфейс)
- не приводят к печальным последствиям, характерным для классических модульных систем.
Описано, в свою очередь, в статьях, ссылки на которые уже были даны выше.
В денежном отношении поддержка системы в целом становится дешевле, без ущерба для качества.
Сформулированный с точки зрения потребителя компонентный подход позволяет получить все преимущества модулей без их недостатков — то есть полностью сохраняя монолитность архитектуры в целом.
Теги: #ERP-системы #ЭД #информационная архитектура #проектирование #модули #Компоненты #промышленная автоматизация #программирование #Анализ и проектирование систем #Промышленное программирование
-
Вот Такой Он - Фарфор В Livejournal
19 Oct, 24 -
Как Я Бросил Курить, Несмотря На Алана Карра
19 Oct, 24 -
Что Не Так С Сервисом Livents.ru
19 Oct, 24 -
Рейтинг Блога Яндекс Сломался?
19 Oct, 24
