В настоящее время информационные технологии достигли высочайшей степени автоматизации разработки программного обеспечения. Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами. У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.
Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно? Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.
Это напоминает упорное кодирование на ассемблере используя безусловно хорошие регламенты и инструменты, которые чуток облегчают наше суровое занятие, вместо того чтобы выйти на другой уровень – использовать новые языки и библиотеки, которые позволяют просто писать алгоритмы, не отвлекаясь на работу с устройствами и рутинными операциями.
Скорее всего, проблема кроется в том, что мы привыкли так делать. Существующая индустрия разработки, инструменты, УЯП сверхвысокого уровня, рынки обучения, найма и продвижения достались нам по наследству. А ещё есть страх машинерии, которая должна связывать все наши компоненты и поддерживать масштабирование, из-за которого мы порой забываем об императиве предметной области и превращаем себя в леммингов, занимающихся обслуживанием вспомогательных механизмов.
Всё это – тот монолит, который мы пытаемся масштабировать хотя бы на наше настоящее и надеемся, что будущее придёт и превратит ком грязи в карету. Но так не бывает! Мы сами должны это сделать. Мы и есть будущее!
Пожалуй, довольно пафоса. Давайте попробуем взглянуть на проблему с той стороны, с которой она должна быть рассмотрена, а не с той, с которой мы боимся на неё не смотреть.
Начинаем с описания предметной области
Для того, чтобы описать предметную область и иметь возможность формально обрабатывать это описание с помощью существующих технологий, нужен язык описания именно предметных областей. Проблема современных УЯП в том, что они слишком универсальны. Они обслуживают универсальные парадигмы, имеют алгоритмическую или другую семантику, не относящуюся прямо к семантике описания предметной области. Они прекрасно справляются со связыванием компонентов, что безусловно полезно, но слишком избыточно.
Как это не банально, но язык описания предметных областей должен обладать семантикой описания предметных областей. Только в этом случае можно будет действительно удобно формировать модель предметной области, не отвлекаясь на второстепенные конструкции. Фокусироваться на декомпозиции предметной области на взаимодействующие подобласти, а не продумывать механизмы связи между ними. Таких семантик может быть много, но для начала выберем одну из достаточно универсальных техник манипуляции предметными областями – Domain Driven Design (DDD) [1, 2].
Позже мы вернёмся к вопросу выбора семантики. Очевидно, выбор будет зависеть от конкретной предметной области, но точно не от инфраструктуры и архитектуры программного обеспечения (ПО) и не от наличия на рынке программистов на конкретном УЯП!
После выбора семантики описания предметной области можно определить синтаксис, который наилучшим образом её отражает. В итоге получится язык, который можно условно назвать Domain Driven Language (DDL). Далее будет приведён пример кода на этом языке. Но сначала давайте посмотрим, как это может работать.
На рисунке 1 приведена условная схема формирования информационной системы (ИС) на базе описания предметной области с использованием DDL.
Ключевым моментом является формирование из описания предметной области на DDL «чистой» семантики [3], которая на самом деле может являться набором стандартизированных JSON-документов и фрагментов кода на каком-либо УЯП, на основе которых, плюс заготовки для конкретной архитектуры, собирается ИС.
Условно названная «DevOps»-команда формирует компоненты архитектуры и инфраструктуры. Это сродни формированию библиотек компонент для различных сред работы приложения и в идеале может выполняться совершенного независимо от предметной области. Нужно лишь соблюдать соглашения о формате «чистой» семантики, не зная о её содержимом.
Можно видеть, что при такой схеме работы не столь важно в какую архитектурную и инфраструктурную среду мы помещаем автоматизацию предметной области. Вся эта машинерия, как и положено, находится под капотом. В результате может формироваться микросервисная архитектура с использованием заранее заготовленных компонентов и фреймворков для браузерного или мобильного UI. А может – монолит настольного приложения в архитектуре махрового клиент-сервера. Да что угодно! И даже всё вместе! При одном и том же описании предметной области.
Некоторые новые возможности
Первое, что может спросить frontend-разработчик: «где же разработка пользовательского интерфейса»? Впрочем, это касается и остальных компонентов архитектуры: неужели пользователи будут довольствоваться автоматически генерируемыми неотёсанными версиями компонентов вроде интерфейса пользователя и других важных частей, которые вручную можно сделать гораздо более красивыми, удобными и оптимальными?
Конечно нет. В смысле действительно есть возможность на основе «чистой» семантики автоматически генерировать и интерфейс пользователя, и структуру базы данных, но никто не запрещает это делать вручную. Особенно в критических местах. Для этого случая можно дополнить схему разработки из рисунка 1 группой UI-дизайнеров, которые формируют важные элементы пользовательского интерфейса. Однако эти и другие группы желательно размещать под «чистой» семантикой.
Важно заметить, что на рисунке 1 изображена упрощённая схема, которая не отражает многих важных особенностей предлагаемого подхода в разработке ПО. Например, не показано, что может работать несколько DDD-команд, каждая из которых реализует свой ограниченный контекст предметной области. И не отображена возможность автоматизировать не только формирование ИС, но и взаимодействие этих команд, а также интеграцию этого взаимодействия в общем репозитории, баг-трекинге, вики и других инструментах организации разработки сложных программных систем.
Ещё одной особенностью подхода является возможное формирование расширений семантики DDL для учёта каких-то особенностей конкретной предметной области. Для этого можно использовать расширенную трактовку контрактного программирования [4].
Да много чего ещё может появиться интересного при таком подходе. В качестве ещё одного примера можно привести раннюю диагностику проблем в рамках семантики DDL, которая гораздо строже семантики любого УЯП. Это означает, что многие потенциальные проблемы, которые невозможно диагностировать при формировании кода на УЯП, будут подсвечиваться редактором при вводе описания модели предметной области на DDL, причём с учётом расширенных контрактов [4].
Рассмотрим простой пример
В качестве примера можно рассмотреть модель предметной области заказа в интернет-магазине – пример весьма канонический, знакомый и «любимый» многими. На рисунке 2 приведён скрин описания заказа на прототипе DDL в интегрированной среде разработки системы SIMODO [5, 6].
В приведённом примере значимые типы и атрибуты записываются на т.н. «общем языке» предметной области и могут автоматически формировать элементы UI и базы данных, что должно обеспечить пользователям знакомую среду работы.
Было бы крайне любопытно посмотреть на описание ваших предметных областей на этом языке, возможно, с использованием некоторых расширений (в виде модулей или дополнений в синтаксис языка), которые покажутся необходимыми. Это помогло бы в разработке языка. Можно предложить и свой синтаксис DDL.
Другие семантики предметных областей и предметно-ориентированные языки
Ранее было замечено, что семантика DDD – одна из многих возможных и для каких-то областей может быть совершенно неприменима. В качестве примера можно привести предметную область имитационного моделирования динамических систем, где модели естественным образом записываются в виде систем обыкновенных дифференциальных уравнений. Для этой предметной области естественным будет описание модели на специализированном языке дифференциальных уравнений.
На рисунке 3 приведен скрин с описанием модели на языке дифференциальных уравнений, а также фрагмент описания запуска процесса моделирования на языке, являющимся базовым для других предметно-ориентированных языков (ПОЯ).
Приведённый пример показывает, что можно использовать несколько языков, каждый из которых описывает свой участок предметной области. На рисунке 4 приведён фрагмент схемы из рисунка 1, который показывает более эффективное формирование модели предметной области, т.к. часть модели формируется специалистом собственноручно (безусловно, при этом может использоваться собственный ПОЯ, не обязательно только язык дифференциальных уравнений).
Таким образом, данный подход существенным образом привлекает специалиста предметной области к автоматизации своей работы, что ещё больше (по сравнению даже с Agile) увеличивает, как итеративность, так и качество процесса разработки.
Может показаться, что данный подход неоправданно сложный, т.к. необходимо поддерживать довольно большое количество ПОЯ. И не безосновательно. Однако почти любой новый подход бывает сложным. И на этот счёт разработан метод автоматизации разработки языков с использованием единой операционной семантики и расширений для интерпретаторов семантических дополнений [3].
Заключение
Предлагаемый подход обеспечивает кардинальную изоляцию предметной области от архитектуры и инфраструктуры разрабатываемой информационной системы, что должно позволить выбирать или менять компоненты архитектуры и инфраструктуры с минимальным влиянием на автоматизируемую предметную область. Также при использовании данного подхода, должно существенно сократиться не только время разработки, но и количество разработчиков на УЯП. А это значит, что разработка будет стоить значительно дешевле, чем при существующих подходах.
Одним из решений, предлагаемых для реализации данного подхода, является создание инструмента, автоматизирующего разработку языков для предметных областей, в том числе для DDD, как предметной области автоматизации предметных областей. Такой инструмент в настоящее время разрабатывается на кафедре ИУ6 МГТУ им. Н.Э. Баумана.
Библиографические ссылки
Эванс Э. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2011. – 448 с.
Вернон В. Реализация методов предметно-ориентированного проектирования. : Пер. с англ. – СПб. Ж ООО «Диалектика». 2019. – 688 с.
Иванова Г.С., Фетисов М.В., Малкина Т.А., Ралдугина А.В. Унификация работы с предметно-ориентированными языками и открытая программная архитектура в адаптивной системе имитационного моделирования // Динамика сложных систем. 2021. T. 15. № 3. С. 36−47. DOI: 10.18127/j19997493-202103-03
Ivanova G.S., Fetisov M.V. The concept of contract management in the base language of the adaptive modeling system. [Электронный ресурс]. URL: https://summa.stu.lipetsk.ru/assets/Final_programm.pdf (дата обращения: 05.12.2021).
Иванова Г.С., Жильцов А.И., Фетисов М.В., Чулин Н.А., Юдин А.Е. Адаптивная система моделирования. – Автоматизация. Современные технологии, номер 11 за 2020 год, стр. 500.
SIMODO/stars в репозитории МГТУ им. Н.Э. Баумана. [Электронный ресурс]. URL: https://bmstu.codes/lsx/simodo/stars (дата обращения: 05.12.2021).
Часть материалов и статей ещё не обработана или являются платными.
Комментарии (23)
OlegZH
12.12.2021 20:43Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами
Это означает, что хорошо поработали системные аналитики. И только уже потом программисты садятся за программный код. Другое дело, что нужно не минимизировать зависимости, а делать их явными и предсказуемыми. Чтобы каждая команда понимала, где у неё вход, а где у неё выход. То, что делает отдельная комаанда — это реализация преобразования, переводящего то, что находится на выходе, в то, что должно находиться на выходе. Теория функциональных систем, однако!
FetisovMichael Автор
12.12.2021 21:00Однако при гибкой разработке (Agile) аналитиков может не быть совсем. За счёт коротких итераций. См. почти любую методологию на базе манифеста Agile, например Scrum, где аналитик опционален. Техника, рекомендуемая в DDD тоже предлагает решение на этот счёт: общий язык, на котором общается команда должен быть языком предметной области, это значит, что просто переводчик с этого языка для разработчиков не нужен. Если, конечно нет других задач для аналитика.
Bazist
13.12.2021 01:05+1Смысл аналитика в том, чтобы ходить по стройке как дизайнер, мысленно визуализировать что должно примерно получится и ставить задачи прорабам и строителям. Совершенно не понятно причем тут длина итераций и как можно обойтись без аналитика. Эту роль кто-то должен выполнять, если проект в активной фазе строительства.
FetisovMichael Автор
13.12.2021 09:03+1Аналогия со строительством в настоящее время совершенно неуместна, см. мой комментарий выше.
FetisovMichael Автор
13.12.2021 10:24Длина итераций важна чтобы усилить обратную связь и вовлечённость заказчика в проект. См. Agile и соответствующие методологии разработки ПО, например.
Можно заметить, что на протяжении эволюции ИТ длинна итераций сокращалась. Если каскадную модели можно назвать одной длинной итерацией, которая чаще всего занимала весь период разработки и внедрения проекта, то такие методологии как RUP или MSF, которые пришли на смену, сократили эти итерации, за весь проект их могло быть несколько, и заказчик мог влиять на ход проекта существенно сильнее.
Гибкая разработка и соответствующие методологии ещё сильнее сокращают длительность итераций за счёт отказа от некоторых документов, например ТЗ, спецификаций и др...
Длина итераций имеет значение... :-).
OlegZH
12.12.2021 20:46+1У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы.
Если бы опыт разработки различных программистов можно было бы как-то аккумулировать... На деле получается, что огромное количество программистов постоянно решает одни и те же задачи, но никто не приводит различные решения к общему знаменателю.
FetisovMichael Автор
12.12.2021 21:04Таких аккумуляций много. Тот же DDD. Паттерны проектирования, MVC... Микросервисная архитектура, DevOps... Это только то, что сразу приходит на ум.
OlegZH
12.12.2021 20:56Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему.
Здесь, почему-то, хочется что-нибудь процитировать из книжки Сергея Тарасова Дефрагментация мозга. Софтостроение изнутри, но для этого придётся перечитать эту книгу.
Впрочем, одну цитату можно привести уже сейчас:
Рассмотренная выше подсистема состоит из минимального набора слоёв трёхзвенной архитектуры на основе веб-служб. Тем не менее даже в таком минимальном варианте обилие деталей, промежуточных и служебных классов, проекций и преобразований должно дать представление о проблеме сложности современного состояния софтостроения. Одним из способов обхода этой проблемы является описанная технология программной фабрики, несомненно далёкая от совершенства и ограниченная в наборе целевых платформ.
...
Таким образом, соотношение числа строк мета-кода описания модели к коду его реализации на конкретных архитектурах и платформах составляет около 600 к 30 тысячам или 1 к 50. Это означает, что оснащённый средствами автоматизации программист с навыками моделирования на этапе разработки рутинного и специфичного для платформ/архитектур кода производителен примерно так же, как и его 50 коллег, не владеющих технологией гене- рации кода по моделям. Любое внесение изменений в модель тут же приводит в соответствие все генерируемые слои системы, что ещё более увеличивает разрыв по сравнению с ручными модификациями. Наконец, для генерируемого кода не нужны тесты. Производительность возрастает ещё как минимум вдвое.
Даже если принять во внимание, что доля рутинного и прочего инфраструктурного кода по отношению к прикладному, то есть решающему собственно задачи конечных пользователей, снижается с масштабом системы, есть о чём поразмыслить в спокойной обстановке.
hungry_forester
13.12.2021 09:48Этим идеям лет тридцать (начиналось с т.н. баз знаний... потом попытки изобрести всякие там DSL...), и я всю дорогу наблюдаю за тем, как они при практическом применении превращаются в обычное "база данных + бизнес-логика" :) Привет коллегам по альма-матер.
FetisovMichael Автор
13.12.2021 09:57+1Салют!
Многие идеи ждали соего воплощения долго, до тех пор, пока не созревали условия. Взять хотя бы парадигму функционального программирования и лямбда-исчисления...
У меня нет уверенности на 100%, что получится, но есть план двигаться в этом направлении. "Дорогу осилит идущий" (с) Кто-то.
К сожалению, в "академической среде" не хватает дискуссионной площадки, где можно было обсудить эту тему. Или я её не нашёл пока.
OlegZH
Крайне любопытно, что из этого получится. Вообще, давно пора вернуться к ситуации, когда мы, находясь в пределах СУБД (подходящей архитектуры, хотя бы, даже, и реляционной), описываем все свойства и особенности хранимых и обрабатываемых данных, а уже пользовательский интерфейс возводится над этими описаниями. Причём, этот интерфейс может быть на клиенте (один интерфейс на стационарном компьютере, возможно, и с несколькими мониторами, другой — на смартфоне), быть на (банковском )терминале...
FetisovMichael Автор
Тут речь идёт о способе описании предметной области в таком виде, чтобы разработка и сопровождение ПО было максимально независимо от баз данных в том числе (от пользовательского интерфейса, конечно тоже). В этом случае можно было бы менять СУБД с минимальными изменениями в бизнес логике, а в идеале без изменений.
Bazist
В статье много фундаментальных правильных мыслей. Которые являются основой того, где все будет через лет 50. Но этот комментарий просто умножил все на ноль. СУБД это основа из основ. Ваш комментарий можно рассматривать как: Я хочу строить дома с взаимозаменяемым фундаментом, главное чтобы крыша и обои с плиткой в доме не потрескались. Что можно построить с таким архитектурным планом - неизвестно.
FetisovMichael Автор
Аналогия со строительством устарела уже как минимум на 20 лет, когда Мартином Фаулером был обозначен термин "рефакторинг". Расскажите, пожалуйста, как происходит рефакторинг в строительстве? А в разработке ПО это ежедневная практика для большинстрва проектов. Аналогия со строительством была очень хороша на заре развития ИТ, когда доминировала каскадная модель жизненного цикла разработки ПО.
Что касается СУБД. Дело в том, что вы в своём посте ставите БД на первое место, по сути объявляете её главенство. В современной разработке это уже не совсем так. В DDD, например, речь идёт о хранилище - некоторой прослойке, уменьшающей зависимость от конкретной СУБД и улучшающей возможности тестирования приложений. Ещё пример: брокер сообщений для микросервисов Apache Kafka, который, не являясь СУБД, может выполнять роль хранилища для некоторых задач.
В своей статье я хотел подчеркнуть первостепенное значение бизнес-логики, всё остальное - вторично, в том числе и БД. Именно этот тезис на мой взгляд должен позволить существенно продвинуться в автоматизации разработки. Если получится, то может случиться примерно такая же революция в ИТ, которая была при переходе в написании программ с машинных кодов и ассемблера на универсальные языки программирования.
vfabr
Основа информационных систем это информация. Информация первична, а алгоритмы вторичны. Бизнес-логика определяется данными, а не наоборот. К тому же, при недостатке информации на входе вы получаете логику, которая плохо аппроксимирует домен и при получении новой информации вы производите рефакторинг (передекомпозицию). Данные переживают и логику и код. При этом я согласен, что СУБД не основа ИС.
FetisovMichael Автор
Думаю, ваш изначальный тезис ложный. Основа ИС не информация, а обработка информации. Сама по себе информация важна, но без обработки никому не нужна. Даже на статическом сайте информация для отображения у пользователя должна быть обработана. Хотя бы переобразована из HTML на сервере в DOM на клиенте (в браузере), а ещё передана. Или вы эту обработку не считаете? Тогда где граница между "чистой" информацией и её обработкой?
Информацию и данные можно рассматривать лишь как способ сохранять состояние объектов бизнес-логики (предметной области). Однако каким именно образом я буду это делать определяется из конкретной ситуации. Например, если надёжность инфраструктуры будет достаточно высока, можно хранить состояние в памяти компьютера (если её заведомо хватит, конечно), не используя ни СУБД, ни какие-либо другие хранилища.
vfabr
Почитайте определение информационной системы, обработка там на последнем месте.
FetisovMichael Автор
Определения одного понятия бывают разные. Некоторые мне нравятся больше, некоторые меньше :-).
Bazist
В строительстве рефакторинг, это когда дядю Васю просят поменять трубы, например чугунные на пластиковые, которые проржавели и протекают.
Здесь нужно определится. Если вы за "соврменную разработку", тогда она мало имеет отношения к озвученным розовым пони вверху. Если разработка "не современная" то на БД вполне можно переложить функции DDD, схлопнув огромное количество ненужных слоев между UI и DB. Чтобы писать что-то декларативное с контрактами на вашем же скрине c инвариантами.
FetisovMichael Автор
Можно сформулировать так: если приложение достаточно сложное, разделимо на модули или подсистемы, требует участия хотя бы нескольких команд, а также мы не имеем точной и окончательной постановки, то крайне желательно предусмотреть устойчивость его кода к изменениям (иногда это называют адаптивностью). Для этого можно использовать различные приёмы и методики. При большом объёме уже написанного кода, при попытке что-то поменять в функциональности или добавить новую, изменения придётся проводить через все слои архитектуры, которая для больших приложений важна.
Если упор делается на предметную область и связь с остальными слоями архитектуры автоматизирована, вплоть до генерации, то затраты на изменения можно существенно сократить. Об этом в статье. И эта мысль хорошо перекликается с цитатой из книжки Сергея Тарасова Дефрагментация мозга. Софтостроение изнутри, которая приведена в сообщении от OlegZH ниже.
Если приложение простое и делается одним-двумя разработчиками, то можно и "схлопнуть" - они и так "дожмут" разработку. Пару ночей не поспят, но доделают, если что.
Возможно, я не вполне понял, что вы имели в виду под термином "современная разработка". Если так, то поясните, пожалуйста.
Bazist
Мысль понятна. Вся магия происходит в неком генераторе кода. Конструкторов NoCode/LowCode сейчас сотни на рынке. Но, на мой взгляд, основная проблема что каждый конструктор мечтает стать новой парадигмой программирования, но остается лишь набором шаблонов.
FetisovMichael Автор
Согласен. Спасибо за комментарий и вам и всем участникам. Было полезно.
Осталось только действительно сделать что-то по-настоящему стоящее :-).