DDD, модульная архитектура и 1С – что общего?

20.09.24

Архитектура - Архитектура решений

Подход DDD гласит, что сложные системы (такие, как 1С) должны разрабатываться на основе понимания предметной области, в которой работает бизнес. Одновременно вместе с ростом конфигураций возникает проблема их доработки, разделения на части. О том, как применять подход DDD и принципы построения модульной архитектуры в 1С, расскажем в статье.

Меня зовут Эмиль Карапетян. Свою карьеру я начинал как системный администратор, с 1С 7.7 познакомился в районе 2006-2007 года. В 2012 году начал кодить на 1С – подрабатывал на фрилансе. Далее руководил проектами, командами и даже отделом. На данный момент являюсь техническим архитектором в компании «Сигма».

Расскажу небольшую предысторию – как я вышел на тропу DDD и начал интересоваться модульной архитектурой.

  • Все началось с того, что меня привлекли к проекту по разработке коробочного продукта на платформе 1С.

  • Затем передо мной встал вопрос о том, как быстро и просто выпускать новые релизы и новые фичи.

  • Потом мне понадобилось дорабатывать ERP на одном из проектов внедрения.

  • Затем встал вопрос, каким образом наладить взаимодействие нескольких команд. Я на проекте был тимлидом команды, и необходимо было так взаимодействовать со второй командой, чтобы не было конфликтов и не были нарушены сроки выпуска релиза. Команда А должна была разрабатывать интеграцию с одним сервисом, а команда Б должна была разрабатывать интеграцию с другим сервисом. Но для работы второго сервиса нужно было получать данные от первого сервиса, поэтому вторая команда была связана с нами по рукам и ногам. Нужно было разделить наши процессы разработки и пустить их параллельно, а не последовательно.

  • В результате всего этого нужно было подготовить почву для создания технической и пользовательской документации.

 

Что такое DDD?

 

Разработка любого программного обеспечения похожа на строительство дома. И мы как разработчики бизнес-приложений в целом схожи со строителями.

Как у нас архитектор подготавливает проект – так же и инженеры в строительстве: чертят чертеж; накидывают, что и как должно быть; выбирают материалы; выбирают место; готовят инструменты; собирают команду. Они делают практически то же, что и мы. Только мы сидим за компьютером, а они нет.

 

Так же, как и мы, строители могут по-разному увидеть результат.

  • К примеру, если мы начертим чертеж в неправильном масштабе, у нас вместо складского помещения получится гараж.

  • Если мы добавим на чертеж окна, у нас уже будет частный дом.

Казалось бы, все начинается с чертежа, но нет – все начинается с вопроса: Для чего это здание? Как мы будем его использовать?

  • Мы будем там что-то хранить?

  • Туда будут приезжать газели или фуры?

  • Мы будем хранить там транспортное средство или ночевать?

DDD как раз-таки отвечает на вопрос: «Для чего это сделано». Эти три буквы расшифровываются, как Domain-Driven Design, предметно-ориентированное проектирование – прежде чем что-то проектировать, мы должны знать, для какой предметной области мы это проектируем.

Казалось бы, мы как 1С-ники это все понимаем, но при этом казусы происходят.

 

Немного истории.

Стандартно процесс разработки программного приложения можно представить как три кольца, движение через которые направлено к предметной области, к Domain (в переводе с английского – предметная область).

  • Сначала мы разрабатываем некий сервис.

  • Далее придумываем, как он будет выглядеть.

  • И уже потом мы решаем, для какой области это все будет реализовано.

 

Но когда сформулировали подход DDD, процесс разработки стал направлен в обратную сторону – от предметной области к конкретному сервису.

 

Когда подход DDD сформулировали, его разделили на две основных части: тактическое проектирование и стратегическое проектирование. Условно, если у нас проект по разработке 1С:Бухгалтерии 4.0 для какого-нибудь Уралмаша, эти уровни будут выглядеть так:

  • Тактическое проектирование – мы открываем конфигуратор и сразу же накидываем туда объекты метаданных.

  • Стратегическое проектирование – мы исследуем предметную область: «А в Уралмаше будет МСФО? А сколько планов счетов? А какие планы счетов? А какие документы? Какие еще операции и бизнес-процессы будут выполняться в Уралмаше?»

 

 

DDD сформулировал Эрик Эванс в 2004 году. Сначала был доклад, позже Эрик Эванс написал книгу «Domain-Driven Design» – ее в простонародье называют просто Blue Book или «Синяя книга». Гуглится нормально: вбиваете «Blue Book, Eric Evans» и сразу найдете.

 

Основная идея книги Эрика Эванса заключается в том, что сложные системы должны разрабатываться на основе понимания предметной области, в которой работает бизнес. По мнению Эрика Эванса, чтобы разработать систему:

  • Сначала нам необходимо узнать предметную область.

  • Потом мы накидываем под нее объекты метаданных.

  • И затем подстраиваем эти объекты под бизнес-процессы – строим бизнес модель.

 

 

Но чуть позже труд и книгу Эрика Эванса переосмыслили. И Вон Вернон выпустил «Красную книгу» – об имплементации подхода Domain-Driven Design.

Вон Вернон сказал, что предметная область – это хорошо, но в основе всего должна быть бизнес модель, мы должны моделировать.

 

По мнению Вона Вернона:

  • Исследуя предметную область, мы сначала должны понять, как будет выполняться бизнес-процесс.

  • А затем уже придумать, как накидывать объекты метаданных, и как они должны быть между собой связаны.

 

И поскольку бизнес-моделирование нам близко, я решил, что если бы DDD придумали в России, это были бы эти два человека.

 

Почему DDD – это про 1С?

 

 

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

 

 

Весь DDD укладывается в три основных принципа – правда, Эрик Эванс и Вон Вернон выделяют больше, но все остальные принципы тоже можно сгруппировать в эти три:

  • Единый язык.

  • Ограниченный контекст.

  • Агрегация.

 

 

Единый язык. Мы, как разработчики на 1С, отплевываемся от наших заказчиков-бухгалтеров, а представители других языков программирования, наоборот, даже собирают словарь, чтобы общаться с бизнес-пользователями на одном языке.

Все же разработчики знают, что такое «крыжить»? Если вы разрабатываете 1С:Бухгалтерию, но не знаете этого слова, значит, вы не находитесь на одной волне с бухгалтерами.

 

Чтобы собрать этот единый язык, нужны эксперты предметной области – эксперты домена. Это должны быть компетентные люди, и они должны сформулировать и собрать вместе с разработчиками единый язык.

 

 

Ограниченный контекст. Звонит Мария Ивановна из бухгалтерии, говорит: «У меня тут на рабочем столе какая-то ошибка, не пойму, что это». Мы ей отвечаем: «Закрой окно». Ну она и пошла, закрыла то окно, что дует. Весь смысл в контексте.

 

 

К примеру, мы разрабатываем какой-то личный кабинет для электронной коммерции. Пользователями нашей будущей системы будут:

  • клиенты;

  • продавцы – возможно, они наш непосредственный заказчик;

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

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

  • У клиента результатом работы с системой будет расходный кассовый ордер.

  • Для продавца нужен отчет по остаткам.

  • Для поставщика – какой-нибудь приходный ордер или сверка заказа поставщику.

 

 

После того как мы сформулируем для каждой группы пользователей свой ограниченный контекст, мы должны сформулировать агрегаты связи между этими контекстами и между сущностями (ядрами контекста). Мы должны связать сущности и продумать:

  • Каким образом клиент будет связан с поставщиком и с продавцом?

  • Как все эти связи ложатся в контекст каждой из групп пользователей?

  • Как мы будем делить все эти бизнес-процессы?

Примерно такие вопросы волновали меня, когда задался вопросом о разработке коробочного продукта.

 

 

Результатом агрегации и формулирования связей между контекстами и сущностями должен стать бизнес-процесс. Мы должны смоделировать бизнес-процесс в любой нотации, хотя бы в самой элементарной – через блок-схемы.

 

Модульная архитектура – как это?

 

 

Теперь о том, что такое модульная архитектура.

В модульной архитектуре каждая отдельная часть программного комплекса связана другими частями минимально – ее отключение или удаление не приведет к какой-то аварийной ситуации.

В качестве примера возьмем один из показанных здесь гексагонов – пусть это будет мессенджер. Если мы этот мессенджер в системе отключаем, у нас все еще должна оставаться возможность открыть настройки и посмотреть уже полученные обращения от пользователей. Это очень важно – отключение модуля не должно повлечь ошибки всей системы.

 

 

Есть три важных принципа модульности:

  • Инкапсуляция;

  • Слабая связанность;

  • Динамичность.

 

Инкапсуляция – это когда мы выделяем части системы в отдельные модули так, чтобы их сущности и методы не соотносились между собой. Например, все, что связано с продажами, не может находиться в закупках. И наоборот.

 

Слабая связанность. Обратите внимание, мы говорим именно о слабой связанности, а не об отсутствии связанности в принципе, потому что модули должны быть связаны между собой – полного отсутствия связей быть не может. Но эта связанность должна быть минимизирована – настолько, насколько это возможно.

 

Динамичность. Ее смысл в том, что каждый модуль нашей системы должен безболезненно обновляться, и после этих изменений не должно происходить ошибок при работе системы в целом.

 

Где в 1С модульная архитектура?

 

 

Как же в 1С связать разные куски между собой, обновить их, и система после этого не упала?

Попробуем зайти в модульность через подсистемы – выделим какую-то часть объектов метаданных и общих модулей и свяжем их в подсистему.

Вроде бы выделили, но модульности не получилось – при обновлении подсистемы мы все равно должны анализировать конфигурацию в целом. Конечно, некоторую легкость при сравнении-объединении мы получаем, но это не то, что хотелось бы.

 

 

Попробуем подойти к модульности через расширения.

На мой взгляд, расширения – это одна из лучших фич, которые придуманы 1С. Потому что через эти расширения можно много чего сделать.

Но есть один нюанс. Когда я слышу: «Расширения? Нет», я сразу вспоминаю сериал из 90-х годов – «Альф». Там Альфу объясняли, что кошек есть нельзя, и он отвечал: «Вы просто их не умеете готовить».

С расширениями можно много чего реализовать, просто нужно их правильно уметь готовить. Само собой, их не нужно пихать туда, куда их не нужно пихать. В принципе, наверное, везде так.

 

DDD + модули + 1С = ?

 

 

Как связать DDD, модульность и 1С вместе?

Когда мне потребовалось применить некоторые знания о DDD и модульной архитектуре, я сделал следующее:

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

  • А основная конфигурация у меня стала ядром этой системы.

 

Выглядит это примерно так – здесь показана конфигурация по автоматизации курьерской службы, которая родилась как раз при попытке реализовать такой подход. Обратите внимание, здесь каждая подобласть и и все, что связано с этой подобластью, выделены в отдельное расширение. К примеру:

  • APIManagementDPO – это расширение, содержащее API для связи с центральной системой.

  • InterfaceOperators – в это расширение я выделил графический интерфейс, с которым будет работать пользователь. Потому что когда мы разрабатываем систему в виде MVP, мы над интерфейсом можем не заморачиваться. Но мы понимаем, что в дальнейшем интерфейс будет меняться. Нам нужно повышать его удобство, чтобы даже простой сотрудник курьерской службы совершал в программе минимум действий – чтобы он мог быстро принимать посылки, быстро их отгружать клиентам. Мы изначально знаем, что интерфейс будет меняться, поэтому сразу же выносим его в отдельное расширение, чтобы удобнее его развивать.

  • DataSendingInterface – интерфейс отправки каких-то данных.

 

Хорошие примеры модульности в 1С:

  • Конфигурация INFOSTART ERP community edition. Она полностью модульная. Идея точно такая же: есть основная конфигурация, являющаяся ядром и много модулей в виде расширений. Классная вещь. Нигде еще не внедрил, но следить за ней интересно.

  • И БСП – почти модульная. Это как раз тот вариант, когда модульность организована за счет подсистем.

 

Выводы

 

 

Какие можно сделать выводы? Признаться честно, некоторые выводы – гипотетические, а некоторые – практические.

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

  • Легкость доработок типовых конфигураций. Это практический вывод, потому что легкость доработок типовых конфигураций через расширение действительно присутствует. Но возможности расширений нужно использовать правильно – если мы замещаем что-то, откидывайте это в отдельное расширение. Не нужно валить в кучу в одно расширение замещаемые объекты и новые общие модули, обработки или формы. Изменения нужно разделять и контролировать внутренними правилами.

  • Сразу, как только мы внедрили модульную архитектуру, нам удалось решить проблемы взаимодействия и обеспечить простоту коммуникации между командами. Казалось бы, модульная архитектура – это что-то техническое, но нет. Коммуникации между командами улучшились, конфликты исчезли, а всего лишь прикрутили что-то техническое. Обычное человеческое взаимодействие было также решено с помощью технического паттерна.

  • С помощью DDD удалось выделить часть функциональности коробочной конфигурации в отдельные модули и решить проблемы с ее оперативной доработкой под конкретного заказчика. Мы сформулировали с бизнес-заказчиками единый язык. Конечно, были некоторые накладки, но взаимодействуя с непосредственным руководителем направления, мы в какой-то момент начали с ним разговаривать на одном языке, быть на одной волне, и пару раз даже четко выдержали сроки.

  • Сопровождение перестает быть мукой. Когда всей команде понятны принципы, по которым сформулированы доработки, их получается развивать быстрее. Логически, исходя из знаний о DDD, мы просто понимаем, где какая ошибка, и как ее быстро исправить.

 

Полезные материалы
 

  • Репозиторий перевода Domain-Driven Design quickly – это книга, которая была написана после выхода Blue Book Эрика Эванса. Она в сжатом варианте. Я ее взялся сам переводить и изучать как раз английский язык. Поэтому если кто-то вдруг захочет, то welcome на репозитории и вместе со мной переводить и изучать DDD.

  • Сайт всё про DDD domaindrivendesign.org – сайт на английском языке, но там очень много информации.

  • Серия статей о монолитно-модульной архитектуре из блога Камиля Гржибека. Это другой вид архитектуры, на него очень похожа архитектура большинства конфигураций 1С. Советую почитать статьи Камиля Гржибека. Это поляк, очень классные статьи, и все очень интересно раскладывает. И после его статей к 1С проникаешься такой гордостью. Чуваки на других языках программирования о таких вещах рассуждают, на которые мы, по сути, плюемся. Я даже когда случайно по GitHub лазил, нашел репозиторий на C#, который написан согласно подходу DDD, и в нем переменные функции называются на русском языке. То есть кто-то где-то плюется, что мы пишем в 1С на русском языке, а там чуваки на C# пишут на русском языке. Я был удивлен.

  • И советую telegram-канал про DDD https://t.me/dddevotion Я на них подписан, у них часто выходят вебинары.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Архитектура решений Бухгалтер Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бухгалтерский учет Бесплатно (free)

При внедрении системы 1С:ERP нередко возникают ситуации, когда поведение программы кажется нелогичным и необъяснимым. Эти моменты могут вызывать замешательство и даже панику, подобно мифическим существам или загадочным явлениям.

12.08.2024    2890    0    user2096116    36    

8

Архитектура решений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Можно ли, окружив СППР доработками, повысить её эффективность? Есть ли такие доработки в готовом виде на рынке? Дисклеймер: данная статья не повторяет мой доклад а лишь излагает мысли и акценты, которые докладчику показались прошедшими мимо слушателей. Если хотите посмотреть доклад, то можно купить доступ или дождаться публикации от Инфостарта.

19.06.2024    1401    0    roman72    0    

2

Архитектура решений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье мы рассмотрим панель системы 1С: Аналитика - План фактный анализ реализации работ заказчикам и вывод о конфигурации 1С: ERP Управление строительной организацией.

24.04.2024    872    0    Koder_Line    1    

1

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Строительство Бесплатно (free)

В данной статье будет рассказано о том, что такое конфигурация 1С:Управление нашей строительной фирмой и какие она имеет функциональные особенности. А также отдельно будет расписан подробно процесс по планированию строительных работ, где будет отображён необходимый порядок оформления всей документации и отчётностей.

22.03.2024    815    0    Koder_Line    0    

2

Архитектура решений Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В данной статье мы рассмотрим, что дает конфигурация 1С: ERP бизнесу, топ менеджменту, специалистам и исполнителям. Основные подсистемы 1С: ERP и их назначение, международный финансовый учет и дополнительные модули 1С: ERP.

22.02.2024    6954    0    Koder_Line    1    

4

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Бухгалтерский учет Управленческий учет Бесплатно (free)

Здравствуйте! В данной статье мы рассмотрим описание системы ТОиР и область ее применения, функциональные возможности и структуру 1С:ТОиР Управление ремонтами и обслуживанием оборудования. В современных условиях динамичных рыночных процессов и стремительного развития технологий, эффективное управление техническим обслуживанием, ремонтом и оборудованием становится ключевым фактором для обеспечения бесперебойной работы предприятий различных сфер деятельности. В этом контексте, система «Техническое Обслуживание, Ремонт и Оборудование» (ТОиР) на базе платформы 1С: Предприятие выступает как неотъемлемый инструмент для эффективного управления всем жизненным циклом технических средств.

24.11.2023    3390    0    Koder_Line    0    

0

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5299    0    ivanov660    10    

34

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Бесплатно (free)

В августе 2023 года увидел свет новый релиз 3.0.7.1 системы 1С:ТОИР КОРП. Третья, наиболее прогрессивная редакция решения для управления ремонтами и обслуживанием оборудования на платформе «1С:Предприятие», активно развивается, обогащаясь новым функционалом и раскрывая всё более широкие возможности для пользователей, которые стремятся повысить эффективность управления активами. Что изменилось в системе с выходом нового релиза?

01.09.2023    1564    0    Desnol_Soft    0    

2
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. gzharkoj 518 20.09.24 20:07 Сейчас в теме
Рекомендую по теме - Хононов В. "Изучаем DDD предметно-ориентированное проектирование".
Когда впервые познакомился с DDD прям сразу ассоциация - это же на 100% про 1С. Когда ее только формулировал Эванс, Нуралиевы на этом подходе уже строили свою империю.
amon_ra; Восьмой; TanyTany; mefalcon; Baszilio; +5 Ответить
3. amon_ra 61 25.09.24 17:43 Сейчас в теме
(1) удивительно, но я наткнулся на эту книгу чуть позже после конференции. Действительно не плохая книга. Сейчас как раз перечитываю
2. Восьмой 89 22.09.24 10:21 Сейчас в теме
Эмиль, приветствую!
Я бы к этой теме еще добавил SOLID принципы и паттерное программирование в 1С
https://leobrn.github.io/ones-patterns/patterns/bridge/
gzharkoj; +1 Ответить
4. amon_ra 61 25.09.24 17:50 Сейчас в теме
(2) Сергей, привет. Оу, как-то мимо меня прошел этот ресурс. Спасибо.
Да, можно, в принципе, добавить, но это уже чуть глубже проектирования, точнее так если говорить конкретно про моделирование архитектуры, то сначала идет DDD, затем следующий слой уже непосредственно паттерны программирования, тогда доклад бы у меня занял точно больше 60 минут)
Восьмой; +1 Ответить
5. Восьмой 89 26.09.24 21:34 Сейчас в теме
(4) Ну вот видишь полезно же)
6. amon_ra 61 03.10.24 14:00 Сейчас в теме
(5) однозначно полезно. конечно, в идеале бы найти свободное время и написать статью о совмещении принципов, паттернов и ddd для проектирования идеального продукта 1с
Восьмой; +1 Ответить
7. Восьмой 89 08.10.24 16:11 Сейчас в теме
(6) Тут конечно не все так гладко на практике, но на текущем проекте использование паттернов как раз превращает саму разработку в модульную, к примеру:
Есть объект который разрабатывается как базовый класс но при этом мы понимаем что многое из того что мы делаем сейчас нам понадобится в других объектах и мы тут же делаем мост через ОМ:
МенеджерОбъекта = ОбщегоНазначения.ПолучитьМенеджерОбъекта(Ссылка);
МенеджерОбъекта.РасчитатьДанныеПоРезультатуИнтеграции();

ну и т.д.
Самое главное в этой истории чтобы все участники команды принимали такой подход и использование паттернов с шаблонами. Если в команде нет архитектора и каждый разраб сам за себя то о DDD говорить смысла нет)
Оставьте свое сообщение