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

Поделюсь цитатами оттуда:

» .. Архитектура – это вообще такая штука, которую невозможно закончить; всё время что-то дорабатывается, совершенствуется, всё время требует большей работы. Мы начали эту работу с разрушения, разборки, деконструкции..

» .. было такое чувство, что его вообще никто и никогда не проектировал. В течение многих лет оно достраивалось и видоизменялось по мере того, как появлялись новые технологии..

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

» .. Мне нравится минималистичная и чувственная архитектура. Главное в архитектуре – это процесс. А методология – ключевой компонент творческого процесса..

» .. Для того чтобы [создание] .. было экономичным, в технологии его постройки должно быть много повторяющихся элементов..

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

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

» .. Проект оказался успешен также и потому, что я лично контролировал не только проектирование, но и закупки, девелопмент, финансирование, и осуществлял авторский надзор [за всеми работами]..

..

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

В этом интервью можно найти ещё много занятного, оно заслуживает большего анализа, чем я попытался показать вам: http://archi.ru/world/69673/rikardo-bofill-kak-tolko-post-modernizm-prevratilsya-v-stil-i-stal-ironichnym-ya-perestal-im-interesovatsya.

Неважно, есть у вас архитектор в проекте, или нет; проектируете вы архитектуру системы или не проектируете явно, а все дружно её "отливают" в материале, у вашего решения всё равно будет какая-то архитектура. Хорошая или плохая, это уже другой вопрос. Напоминаю, что архитектура это всё, что а) важно б) очень трудно и дорого поменять

Разработчик считает, что API сервисов — то, при помощи чего приложения соединяются друг с другом.  Архитектор решения считает, что API сервисов — то, при помощи чего приложения друг от друга отделяются.

*** Как бы реклама (шкурный интерес) ***

Друзья, я чуть ранее упоминал, что наш рабочий коллектив растёт и ширится. Мы ищем на позицию архитекторов IT-решений (Solution Architect) людей, которым небезразлично то, о чём я писал и пишу в канале.

Мы можем предложить участие в масштабных проектах по развитию информационно-аналитических и оперативных систем на базе проприетарных (IBM, Oracle) и свободных (Apache, Google, Redhat, Mozilla и других) технологий в области здравоохранения, складской логистики, систем массового обслуживания.

Требования такие:
* Опыт работы в качестве архитектора сервис-ориентированных и распределённых систем, систем массового обслуживания и систем хранения данных высокой доступности
* Опыт проектирования реляционных и других хранилищ данных
* Опыт работы с технологиями JavaEE в роли ведущего разработчика, технического лидера проекта
* Опыт разработки качественной проектной документации
* Знание архитектуры современных программных приложений, методологий проектирования программного обеспечения, а также наличие широкого IT-кругозора. Знание технологических особенностей различных СУБД, платформ разработки приложений, операционных систем и технологий разработки, развёртывания и взаимодействия приложений, подсистем и компонентов. Большим плюсом будет знакомство с технологиями моделирования архитектуры предприятий SysML, Archimate

Типовые обязанности:
* Участие в проведении обследования системы и анализа требований к системе
* Участие в разработке технического задания
* Разработка архитектуры решения (концептуальный и технический дизайн)
* Выполнение обязанности технического надзора в проектной команде разработки (участие в постановке задач, консультирование)
* Взаимодействие с командами аналитики, тестирования и архитекторами смежных систем
* Участие в формировании требований и развертывании среды функционирования

Писать @meowthsli

И чтоб два раза не вставать — набор фронтендщиков мы тоже ведём активно, в т.ч. готовы прикупить "бедствующие" команды (5-10-20 человек) целиком либо запартнёриться. Работы реально много.

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

Распорядителем и секретарём всего процесса является руководитель проекта. Он вместе с прикладными экспертами готовит концепцию по некоторой теме, которую предлагается овеществить в IT-решении. В концепции прописано языком пользователя (а точнее, спонсора), что мы хотим сделать, зачем, какой профит получат заинтересованные лица. Также там прописываются критерии успеха (например, "к началу следующего года 75% приёмов пациента должны проводиться через новую, голосовую версию интерфейсов").

Эта концепция, при необходимости, детализируется аналитиками до уровня процессов и практик. Некоторые шаги этих процессов и составные части практик маппируются на систему — обозначается, что они поддержаны будущим решением (например, "система позволяет медработнику завести электронную карту" и т.д.).

Полученный документ бизнес-анализа поступает на вход архитектору решений. У нас их пул, людей из этого пула зовут ещё главными инженерами проекта (ГИПами). Это те люди, кому предстоит держать в голове весь проект как систему целиком. На основании переданных материалов ГИП готовит документ с архитектурой решения.

Это документ, по сути, содержит вот что:
- перечень приложений, задействованных в будущем решении.
- связи и протоколы между этими приложениями.
- концептуальное представление всего внешнего и иногда внутреннего API системы.
Очевидно, что эти перечни не берутся с потолка, а являются итогом различных активностей, от прототипирования (выполнение ОКР) до подбора на рынке.
В этом же документе задаются нефункциональные требования, рассчитанные уже на уровень технических показателей, SLA, требования к использованию тех или иных инструментов, практик, подходов, фреймворков и технологий. Эти документы, упомянутые выше, проходят некоторое согласование ("защиту") у заказчика — чтобы утвердиться, что мы поняли его верно и делаем нужную вещь.

Далее, руководитель проекта получает документ с архитектурой решения, вписанного в текущий системный ландшафт. На основании него, определяет, какие приложения (у нас это называется "продукты", у каждого из них есть владелец и свой план релизов и жизненный цикл) надо доработать или вообще разработать с нуля. По итогам составляет план:
- доработки существующих продуктов заказываются у владельцев продуктов (= роль в разработчике, закреплённом за продуктом).
- под разработки продуктов с нуля подбираются разработчики.
Под каждый продукт на основании предыдущего пакета готовится ЧТЗ, часто силами самого разработчика, в т.ч. — детальные спецификации контрактов и протоколов. С их помощью каждый владелец продукта сообщает свои планы, когда он сможет закончить свою часть разработки.
Руководитель интегрирует эти планы в общий план, утрясая совместные релизы. Количество продуктов на доработку является критерием сложности проекта; проекты сложнее 4-6 единиц мы делим на этапы.

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

Опущу процесс проектирования UI, разработки и прохождения внутреннего тестирования: там ГИП нередко участвует как автор критического кода, а также как представитель группы надзора по качеству артефактов от разработчика. Разработчик в процессе работы создаёт и предоставляет корреспондентам: детальное ЧТЗ, документ с архитектурой своего приложения, детальные контракты API, схемы данных, инструкции по сборке и развёртыванию.

Далее ГИП участвует в процессе развёртывания в тестовых (для приёмочных испытаний) и продуктивных контурах и опытной эксплуатации решения — согласование набора программы и методики испытаний, согласование документов на выделение комплекса технических средств (инфраструктура, middleware), разбор инцидентов, поддержка решения в продуктивной среде, внесение срочных правок (хотфикс) по итогам пилотирования.

Процесс уже настроен достаточно хорошо, что позволяет сосредоточиться на конкретных прикладных особенностях решения, без боязни что-то потерять.

Процесс работы непрерывно эволюционирует, появляются новые активности, изменяются понимания, что нам необходимо отразить в тех или иных артефактах. Это мы считаем нормальным.

Работы над проектом не выполняются по модели водопада: многие артефакты создаются параллельно разработке и самими разработчиками.

Что такое DDD, domain-driven design? Если вы не разобрались для себя раньше, то следующие несколько записей я посвящу этой теме.

DDD это такой набор систем взглядов и подходов, который определяет cпособ разработки в целом, а прежде всего, способ анализа, постижения устройства той части мира, в которой предстоит разобраться проектировщику. В 2002 году Мартин Фаулер выпустил книгу «Шаблоны архитектуры корпоративных приложений». Книга даже на данный момент не перестала быть классикой по разработке корпоративных приложений. В частности Мартин приводит три шаблона по организации бизнес-логики в проекте:
1. Transaction script
2. Table module
3. Модель предметной области (domain module)

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

При достаточно сложной логике и при большом объёме приложения – этот метод плохо работает, потому что у нас получается макаронный код, «копи паст». И что намного хуже – при такой организации конкретная прикладная логика распределяется по всей кодовой базе – однажды определённая функция может понадобиться какой угодно другой, и если мы организуем вызов одной из другой – значит, мы связываем их тесно с риском сломать вторую при правках первой (или копипастим логику со всеми рисками этого решения).

Table module – это чуть другой подход. Он заключается в том, что мы выделяем классы-сущности, которые так или иначе обозначают таблицу интересующих нас понятий, фактически таблицы базы данных. Иногда к каждой таблице, кроме класса, сопоставляется (достаточно механически) некоторый другой код и классы – кроме сущности Zzz, появляются ZzzDao, ZzzRepository, ZzzManager, ZzzHelper и так далее.
Все классы обладают какими-то операциями, они что-то уже умеют, что-то в себе инкапсулируют. Как правило, они инкапсулируют работу с базой данных. В частности – могут содержать методы: добавить, удалить, получить все записи, и ещё какие-то. Ну и с каждой сущностью мы работаем, запрашивая из таблиц. Очевидно, прямой связи (в терминах кода) у нас между таблицами нет, и мы как-то внутри нашей программы строим их вручную там, где это надо.
Иногда к этому подключается и ORM, который как-то упрощает ситуацию, уменьшая количество рукописного кода. Но, фактически, если кто-то работал с MS Visual Studio или вообще с технологиями MS, — это то же самое, что RecordSet, или DataSet, только написанный вручную. До 2008 года это были основные технологии по работе с данными.

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

Как развитие этого шаблона в 2003 выходит книга Эрика Эванса «Предметно-ориентированное проектирование» (в оригинале Domain Driven Design structured complex software systems). Эта книга содержит не только описание шаблона "модель предметной области", но и некий набор подходов, которые нам показывают, как нам с таким набором работать, построить и как нам, в конце концов, получить эту модель предметной области.

Вот что нам говорит Эрик Эванс о "столпах" DDD.

Во-первых, DDD это переработка знаний. Те знаний, что у нас есть о предметной области, нужно анализировать; из них надо выделять актуальную предметную область.
Во-вторых, это непременно единый язык. Любая модель даёт нам некоторую терминологию, которая образует свой язык, и с которой мы можем работать, говорить на ней, писать.
И, в-третьих, проектирование кодовой базы по модели (Model Driven Design). Последнее – наиболее техническая часть DDD. Которая обозначает, что мы непосредственно нашу придуманную модель предметной области отображаем в код, и её и только её можем там найти, – именно её, а не какую-нибудь ещё.

В следующий раз мы рассмотрим каждую из этих частей подробнее.

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

Ну так вот.

Когда мы приходим в предметную область и хотим её автоматизировать, то мы ещё не знаем, какая у нас есть модель. И более того, даже те специальные аналитики, которые с ней работают – они могут не до конца знать, какая у них модель. Причём нам нужна не какая-то любая модель, а модель для нашей системы. Скорей всего она немного отличается от общепринятой модели предметной области – там есть либо новые понятия, либо другие понятия, которые более чётко ограничены и более формально определены. И поэтому первым этапом, что мы должны сделать при разработке в соответствии с DDD, — это заняться переработкой знаний нашей предметной области. После того, как мы построили у себя некоторое представление предметной области – мы должны спроектировать модель, логическую модель – то, непосредственно с чем мы будем работать. После того, как модель была спроектирована, мы опять возвращаемся к предметной области и начинаем её рассматривать глубже, более подробно, выделяя новые сущности, делая явным неявное и т.д.. Наконец, когда мы проработали модель, следует опять возвращаться к переработке и извлечению знаний (уже из модели, а не только из бизнеса). Вот такой итеративный процесс происходит.

Что же такое переработка знаний? Как определяет её Эрик Эванс – это поиск абстрактных понятий, учитывающих необходимые подробности. Необходимые для разработки нашей системы, очевидно. Кто выполняет эту переработку знаний? Специалисты предметной области, разработчики системы – не в узком смысле только программисты, а ещё аналитики, тестировщики, руководители проектов. Но важно, что здесь должны присутствовать те, кто будет писать код, кто понимает, как будет выглядеть архитектура системы.

Вот пример.

Простейшая задача – рассчитать зарплату сотрудника в заданном месяце. Многие, наверное, знают, что зарплата рассчитывается далеко не так просто, как хотелось бы. Допустим, эксперт нам говорит, что: "Отношение количества отработанных дней к количеству рабочих дней в месяце умноженное на отношение оклада сотрудника к количеству рабочих дней в месяце". Очевидно, в той фразе присутствуют такие понятия, как сотрудник, месяц, количество рабочих дней, оклад сотрудника. Мы спрашиваем у специалиста, а что такое отработанный день. Получаем ответ: "Рабочий день, когда сотрудник присутствовал на рабочем месте, при этом он ещё не уволился". У нас появляется новая сущность, это какой-то ДЕНЬ, очевидно, он выделяется явно, имеет отношение с сотрудником и с месяцем, имеет у себя атрибуты «рабочий\выходной», «присутствовал».
Дальше специалист предметной области вспоминает, что у сотрудника ещё могут быть отпуска или он может быть на больничном и там всё по-другому, там другая ставка, другие проблемы. Мы рисуем такую модель и уже здесь видно, что неправильно у нас что-то получается – очень много связей. Логично задать вопрос – откуда мы можем узнать, что у нас сотрудник присутствовал на работе, был ли он в отпуске или на больничном? И специалист нам отвечает: «из табеля учёта рабочего времени». Он раньше его не упоминал, потому что для него это было абсолютно естественно. Он не то чтобы нуждается в отдельном упоминании, но вот путём переработки знаний, анализа системы, мы выявили такую сущность и соответственно модель у нас получается гораздо более понятной, когда у нас есть сотрудник, есть его табель учёта рабочего времени, который имеет следующие методы:

   Получить количество отработанных дней
   Получить количество дней в отпуске
   Получить количество дней на больничном и т.д.

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

Вторая составляющая, единый язык (ubiquitous language) – это система терминов и понятий, который у нас получается в результате проектирования DDD.

Не должно быть так, чтобы мы какую-то модель построили, потом выкинули её и начинаем говорить, как попало, с какими-то новыми терминами, что-то объясняя на пальцах. Нет, у нас модель предметной области, именно в её терминах, её отношениях, в её поведении мы должны разговаривать, обсуждать структуру технических заданий и прочее. Язык строится на модели предметной области, он должен чётко из неё следовать. И он же проверяет модель предметной области. Если модель предметной области, которую вы построили – очень-очень сложная и вам сложно это использовать в языке, вам постоянно хочется использовать другие термины и другие предложения – это значит, что у вас неправильно построена модель. Хороший способ проверить, хорошая у вас модель или нет – попробовать использовать её термины на русском языке.

Построенная модель используется во всех документах. Т.е. мы не просто так строим какие-то модели, разговариваем, и всё, дальше разработчики начинают городить микросервисы, контроллеры, IoC-контейнеры, фасады и прочее.

Нет, именно на основании этих моделей должны строиться официальные документы, включающие ТЗ, требования, архитектуру системы и т.п., И как ни странно, именно этот же язык должен использоваться в КОДЕ.

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

Третье — проектирование по модели.

Наиболее сложная часть DDD. Сложная она по техническим причинам в силу несовершенного инструментария для всего, инерции мышления и многих других причин. Вот что такое проектирование по модели (по Эрику Эвансу):

"Проектирование по модели (Model Driven Development) – проектирование архитектуры, при котором соблюдаются максимально точное соответствие между некоторым подмножеством элементов программы и элементами модели. Если у нас была модель предметной области – и мы начинаем строить для неё программу - получаем некоторое предсказуемое овеществление в код.

Кстати, правила соответствия сейчас закреплены у нас в документах по "рельсам архитектуры" и доступа к БД, и есть планы их контролировать.

Антипример

Очень часто сейчас у нас получается так – где-то в глубине системы, по её объёму, у нас происходит бизнес-логика – нам так говорят разработчики, мы в это ВЕРИМ, оно так проявляется. Но фактически мы видим, что используются совершенно другие понятия – здесь у нас какие-то датасеты, датаридеры, команды, коннекторы, и прочие вещи, которые в модели предметной области даже и не упоминались. Я уже не говорю, что если вы попробуете разговаривать на этом языке с людьми из предметной области, с людьми для которых вы пишете эту программу, то очень долго придётся объяснять, что вы имеете ввиду. Вот здесь мы видим, что у нас модель аналитики одна, а программа другая. Модель программы оперирует одними понятиями (датасет, коннекшн и т.д.), а модель предметной области – книги, авторы, издатель, читатель и т.д.

Т.е из-за выбранного способа реализации нужно нашу модель предметной области взять и ВЫКИНУТЬ, да? Она, конечно, полезной была, люди, которые её строили, лучше знали предметную область, но таким темпом она очень быстро потеряет свою актуальность. Но ведь модель предметной области имеет гораздо более широкое применение, чем техническая. Аналитики (правильные аналитики) общаются, прежде всего, в ней, она есть самый полный и компактный источник знаний.

Поэтому методика реализации, которая требует её выкинуть, сразу вызывает обоснованные подозрения, и поделом. А та, которая наоборот, считает её ценной — вызывает доверие.

**
В следующем выпуске мы поговорим про минусы и проблемы DDD

Снова я в эфире. Заключительная часть про Domain-driven desing, про его плюсы и минусы.

Зачем нам может понадобиться DDD?

Это эффективный способ борьбы со сложностью. Действительно в сложных системах – хорошая модель предметной области уже сама по себе помогает бороться со сложностью. А когда мы её непосредственно внедряем в код, когда программисты, аналитики, специалисты предметной области все они работают в одних терминах, причём всегда и программисту не нужно думать, как ему из «авторов-читателей-медработников» и других понятий перевести в датасеты, рекордсеты, DTO и сервисы всякие.

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

Практически любую фразу, которую мы говорим на этом языке, мы можем сразу проверить, даже чисто умозрительно — можно ли её реализовать в коде или нет, и как сложно. Как правило, когда у нас код написан в несколько других терминах, на это нужно потратить существенное время. И более того, сам уже по себе единый язык даёт возможность существенно улучшить выработку требований.

Качество проекта и скорость проекта зависит от хорошего определения его scope, по большей части – от полного понимания того, что мы будем делать, а что не будем. Определить это без единой терминологии, постоянно, каждый раз заново договариваясь про то, о чём мы говорим –- достаточно сложно. Уже только одно это помогает снизить стоимость разработки и сопровождения.

Если всё так хорошо, почему мы его раньше не использовали или не принялись прям с завтра? Ну, как минимум, потому что у нас могут возникнуть в применении DDD некоторые проблемы. Не всё так хорошо, как хотелось бы.

Вот минусы DDD

Организационные проблемы: например, разделение анализа и проектирования. Оно может быть как явным образом (в команде присутствуют аналитики и разработчики, которые вообще не участвуют в анализе) так и не явно, просто в голове человека. Пусть этот человек даже не участвует в анализе, но для себя он вначале анализирует и строит какую-то модель, а потом пытается её реализовать. Причём реализовать он её пытается, как правило, как-то по другому, по-своему.
А при DDD, мы должны сразу думать, как мы модель будем реализовывать – в явном виде, в явных терминах, на основании которых мы будем обсуждать потом с заказчиком и со всеми другими участниками проекта новые понятия – это достаточно тяжело, и обычно требуется некий опыт (этот вопрос у нас в компании тоже раскрывается в документе арх. рельсов).

Также часто встречается чисто административная проблема, когда разработчик отстранён от анализа, и разработчики вообще могут ни разу не увидеть, для кого они всё это делают. Часто так происходит, когда выделяется отдельный отдел аналитиков, которые не особо интересуются обратной связью от разработчиков, а то и от пользователей.

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

Например, частое заблуждение — большинство аналитиков проектируют, исходя из предположения, что таблицы в БД – идеальная сущность, которая может бесплатно хранить бесконечное число строк и колонок, все операции над которыми выполняются мгновенно, включая join таблиц, и не зависят друг от друга, от объёма данных и количества таблиц.  Очень часто аналитики могут себе даже не представлять, что бывают нереляционные СУБД, которые могли бы лучше подойти для хранения данных – нет, в модели (даже логической) будут таблицы, которые разработчик может трактовать (в отсутствие архитектурных договорённостей) как требование создать таблицу в БД.

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

Ещё одна причина – отсутствие опыта DDD. Надо сказать, что DDD это – в первую очередь – изменение сознания внутри проектной команды и разработчиков, чтобы они привлекались к анализу и совместно работали на построение модели. Ну и сам по себе Model Driven Design, который является основополагающей частью DDD – требует некой ломки, потому что мы пытаемся внедрить то, что мы придумали в код, — всегда хочется где-то проскочить, не меняя модели, вот здесь взять датасет, там что-то сделать ещё какой-то обходной путь.

Ну и есть ещё множество технических есть проблем, связанных с Model Driven Design. В первую очередь это плохие инструменты, для того, чтобы хранить как-то данные – очевидно, в объектно-ориентированных языках надо использовать какие-то средства. Обычно данные в корпоративных системах хранятся в реляционных базах данных. Это вынуждает нас выбирать какой-то преобразователь из реляционной базы данных в нашу объектную модель. Для этого существует даже много промышленных средств, таких как Hibernate и другие ORM, но все они имеют проблемы, прежде всего – проблему дикой сложности, ORM очень сложен.

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

Иногда спрашивают – ну, вот, у меня есть ООП, что тут изобретено нового с DDD?

Тут надо понимать – ООП подход не призывает нас строить модель той предметной области, в которой мы работаем, ООП подход – это объединение данных с поведением, причём это может быть не связано с предметной областью. Датасеты, которые я приводились в пример, датаридеры, коннекшны – это тоже ООП подход, просто там объекты другие и поведение другое, и они не имеют отношения к решаемой нами задаче и вызваны технологическими причинами.
А DDD это именно набор подходов и взглядов, которые заставляют нас строить эти объекты определённым образом, непосредственно тем, как они устроены в реальном мире. При этом DDD нас призывает не просто как-то строить нашу модель, которую потом собираемся отражать на ООП, а выделяя из неё все понятия явно и близко к тому, как мы о предметной области говорим.  Хороший пример, который показывает, что мы работаем в DDD успешно – когда мы говорим какую-то фразу о правилах предметной области, и она точно также выглядит в коде. Это переход от технических сущностей (листов, баз данных и др. вещей) к бизнес сущностям.

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

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

Но не всё так плохо. Бухгалтер, когда работает с системой, даже с простейшим принт-сервером, получает в распоряжение простейшее понятие – соединение: оно может быть разорвано, его может не быть. Можно сказать, что бухгалтер работает со счетами: дебет-кредит и к чему ему «соединения»? мы не будем вносить это в предметную область. Но понятие есть, и люди им нормально пользуются. Или, к примеру, «связи нет» — даже в любом магазине крупном, где компьютерные системы зависают – все, кто стоят в очереди, прекрасно поймут этот термин. Они есть в предметной области, их можно и нужно туда явно вносить.

Третий способ, который появился в DDD относительно недавно – CQRS, command query request separation, когда у нас сложные технические вещи, как правило, чтение, совсем не попадают в основной домен, а располагаются в своей отдельной модели.

Вот, пожалуй, и всё, что я хотел сказать. Надеюсь, я в кратце смог описать, что такое DDD. Подытожу ещё раз: это переработка знаний, когда мы разрабатываем предметную область; это единый язык, на котором мы все всегда должны между собой общаться; и моделирование на основе предметной области, обозначающее то, что мы модель эту не просто так разработали, а чтобы непосредственно её внедрить в коде.

Сегодня хочу немного восстановить нарушенную справедливость и разрекламировать неновую, но незаслуженно забытую книгу Грейди Буча "Объектно-ориентированный анализ и дизайн".

Создание софта, в т.ч. на ООП это прежде всего синтез корректной модели. Обычно об этом забывают.

Книга написана ещё тогда, когда не существовал UML, и она послужила толчком к его созданию и оформлению. Я предлагаю перевод, по сравнению с оригинальной монографией (найдите её в сети), тут есть примеры только на с++, а не Смолтоллк и других. Но не пугайтесь, кода на с++ в ней нет, зато есть понятные диаграммы — пожалуй, лучшие, что бывают в таких книгах. А ещё — хорошие иллюстрации.

Для ознакомления прикладываю файл, разумеется, его необходимо удалить со своего компьютера после прочтения оглавления :)

После сообщения про DDD мне пишут следующее: скажи, что почитать хорошее по теме. Книга развесистая (Эван, Вейрон), в  интернете написано много, но суть ускользает, у каждого своё видение. Это действительно так: в любой теме так или иначе появляется user-generated content, в котором за достоверность, понятность и вообще соответствие истине никто не отвечает. Даже dddexample (тот, что про грузоперевозки) больше сконцентрировался на разной технической ерунде.

Вот вам пару примеров и источников, которые хорошо и точно передают дух идеи:
1. Статья в блоге — пример дизайна в DDD некоторой простой предметной области https://www.mirkosertic.de/blog/2013/04/domain-driven-design-example/
2. Книга DDD Quickly - must read для понимания https://www.infoq.com/minibooks/domain-driven-design-quickly (бесплатное скачивание)
Даже не знаю, что читать первым. Попробуйте в том порядке, что я написал выше. Если что-то становится непонятно — пропускайте, потом вернётесь

Друзья, через пару-тройку недель планирую выступать с докладом в партнёрской компании CUSTIS (http://custis.ru/).

Буду хоронить 💀 микросервисы, с аргументами. Кажется, все будут топтать за (ох уж эти любители решать проблемы усложнением!), а я -- против.

Анонс будет чуть позднее, да в сообществе CUSTIS в FB напишут тоже.