С самого появления расширений мне понравилось работать с расширениями. Да, в том уже теперь далеком 2014 году, идея применения расширений была порой пугающей, мало кто решался на реализацию доработок типовых или разработок своих нетленок с применением расширений, но эта технология мне приглянулась, и до сих пор я уверен, что это классная штука и у технологии расширений светлое, а может даже и великое, будущее. Возможно благодаря экспериментаторам архитектура расширений так значительно улучшилась. Когда я где-то слышу как кто-то ругает расширения, как они не работают или с их применением система глючит, то я всего лишь цитирую Альфа.
Перейду, пожалуй, к делу.
Давайте представим, что нам требуется разработать какую-то свою нетленочку, допустим для пункта выдачи посылок курьерской службы «Официальные отрезки».
Нам даны примерно следующие требования:
Оператор пункта выдачи курьерской службы принимает посылки от экспедитора и выдает клиентам службы посылки или конверты, кроме того оператор может принимать посылки или конверты от клиентов. У данной программы имеется интеграция с другой системой, которая расположена на удаленном сервере (а может быть и где-то в облаке) в главном офисе «Официальные отрезки».
Любое совпадение с реальным проектом, ТЗ или чьим-то готовым продуктом прошу считать чистым совпадением.
Давайте сформулируем основные условия нашего проекта:
- В программе присутствует возможность выдавать посылку или конверт клиенту
- В программе присутствует возможность принимать от экспедитора посылки или конверты
- В программе присутствует возможность принимать от клиентов посылки или конверты
- В программе присутствует возможность передавать посылки или конверты экспедитору в распределительный центр
- У программы имеется интеграция с другой программой
Таким образом мы выделили основные процессы работы оператора с программой. Давайте теперь попробуем детализировать эти процессы путем уточнения требований у нашего заказчика.
- Оператору поступает информация в его систему из внешней системы о том, что запланировано поступление посылочек. Данная информация может содержать: дату, время подвоза и контактный номер экспедитора
- В момент приема посылок от экспедитора отправляется информация клиенту о том, что посылочка ждет его в пункте выдачи курьерской службы.
- Для передачи посылочек в распределительный центр оператор должен отправить информацию во внешнюю систему
Думаю, для того чтобы заложить некоторый «скелет» или как все сейчас говорят: «подготовить MVP» нам будет достаточно такого описания.
А теперь предлагаю поразмышлять и взглянуть на «сферического коня в вакууме».
Поразмышляли?
Тогда давайте продолжим!
Теперь попробуем выделить области (подсистемы) нашей программы:
- Интеграция с какой-то внешней системой
- Отправка информации
- Получение информации
- Хранение информации о посылках или конвертах
- Прием и передача (выдача) посылок или конвертов в распределительный центр
Итак, мы выделили основные условия нашей задачки, сформулировали области нашей программы, теперь давайте подумаем над тем как же будет выглядеть наш программный продукт для пункта выдачи посылочек. Конечно, как труодинесники мы можем сразу с боем броситься на амбразуру - открыть конфигуратор и начать клепать объекты метаданных налево и направо, как говорится хрясь, хрясь и в продакшн, но давайте на минуточку побудем разработчиками бизнес-приложений и подумаем над архитектурой этого самого бизнес-приложения. Для начала выясним какие бывают вообще архитектуры приложений, в принципе, и для этого погуглим и почитаем педивикию.
Ну, вот поели можно и поспать После чтения гугла мы выяснили, что имеются монолиты, модули, микросервисы и прочие не до конца понятные слова. Все типы, виды и паттерны проектирования архитектуры приложений копипастить из гугла не буду, ибо сейчас нам достаточно будет приведенных трех.
По сути приложение разработанное на 1С считается монолитом, микросервис на 1С та еще наверно задачка, поэтому предлагаю взглянуть на так называемую модульную архитектуру. Как думаете можно ли примерить модульную архитектуру к 1С? Вы скажите нет? Вот и брат мой так считает. А вот я уверен, что можно!
Обратимся все к тому же гуглу:
Модульная архитектура программного обеспечения – это подход к разработке, при котором программа разбивается на независимые компоненты, которые могут взаимодействовать между собой посредством четко описанных контрактов. Эти компоненты – модули – должны обладать несколькими признаками. Первый – инкапсуляция (они должны скрывать свою реализацию от внешнего окружения), второй – слабая связность (модули взаимодействуют только с помощью заранее оговоренных контрактов), третий – динамичность (возможность замещаться «на лету», без необходимости остановки всего приложения).
Попробуем к этому, найденному во всемирной паутине, определению притянуть наши расширения 1С.
- Расширение может скрывать свою реализацию от основной конфигурации или других расширений;
- Расширения могут быть слабосвязанными;
- При подключении расширения или его обновления можно не перезапускать 1С;
- Можно организовать взаимодействие через экспортные процедуры/функции и, в принципе, эти процедуры/функции можно назвать специальными контрактами.
Двигаемся дальше и вспомним о выделенных областях нашего приложения и, опираясь на сформулированные области, попробуем выделить наши модули:
- Модуль API для доступа из внешней системы к нашей программе;
- Модуль отправки информации во внешнюю систему;
- Модуль пользовательского интерфейса для взаимодействия Оператора с нашим приложением.
Кажется у нас чего-то не хватает… Раннее в выделенных областях мы указали пункт связанный с хранением информации о поступлении посылок или конвертов, а так же их выдача клиента и отправка в распределительный центр. Данный пункт отвечает за непосредственное хранение данных и возможную обработку и/или преобразование данных для хранения. Данную область будет правильно отдать основной конфигурации и таким образом, эту самую основную конфигурацию нашего бизнес-приложения мы выделяем в отдельную абстракцию, которая ближе к так называемому ядру всей нашей системы.
В итоге у нас получается следующее: есть одно ядро и три модуля. Каждый модуль отвечает за логическую абстракцию и для реализации связи между модулями и ядром нам теперь требуется определиться с тем какие классы будут в основной конфигурации, а какие в расширениях. Те объекты, которые будут отвечать за хранение данных будем формировать в основной конфигурации, а в модулях определим объекты, которые будут отвечать за обработку тех самых данных.
На этом моменте я бы хотел остановиться и поразмышлять в комментариях об объектах, какие бы вы объекты создали в основной конфигурации, а какие в расширениях и вообще интересно узнать подобный подход кто-нибудь использовал в рабочем контуре?
Продолжение своих размышлений перенесу в другую статью с уже готовым тем самым MVP.
ну, в общем
...
Кстати, в INFOSTART ERP community edition используется модульная архитектура.
А еще у нас в Воронеже есть профессиональное околоодинесное сообщество Желтый клуб
