Год назад Максим Аршинов (marshinov) выступил с докладом "Быстрорастворимое проектирование". Отличный доклад, харизматичный спикер, полезные материалы в конце. Этот доклад изменил моё понимание того что я делал — кто из нас не пытался интуитивно применить pipeline-архитектуру? А тут ещё элегантные решения помноженные на DDD! С этого начался мой путь евангелиста предметно-ориентированного проектирования.

Скоро DotNext 2019 Moscow. Как всегда, ждём обзора новых фичей, обмена опытом, best practies, архитектурных решений — за это мы все и любим конференции. В списке докладов вокшоп "Блеск и нищета предметной модели", который обратил моё внимание. Цитата со страницы:

Фаулер и Эванс считают анемичную модель антипаттерном. Однако многие кодовые базы, с которыми доводилось работать спикеру, реализованы в стиле «анемичной» модели. Доклад посвящен сравнению сильных и слабых сторон обоих подходов и не очевидным деталям реализации модели предметной области в парадигме ООП и в функциональном стиле.

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

Дисфункции использования предметно-ориентированного проектирования

У настоящей ситуации есть некоторое историческое развитие. Рассмотрим поэтапно как развивалась ситуация.

Продвижение

Максим, на мой взгляд — самый известный разработчик, состоящий в комьюнити, который много лет грамотно продвигал DDD, рассказывая о самом понятии, использовании. Честь ему за это и хвала! И я привожу в пример Аршинова, только потому, что считаю его лучшим на данный момент спикером дотнекста.

Дисфункция #1: Рентабельность

marshinov написал несколько статей на предмет стоимости внедрения практик DDD. Вывод простой — предметно-ориентированное проектирование стоит дорого. И суждения справедливы — сам Эванс в своей книге отмечает, что команда должны быть очень квалифицированной, а значит дорогой. Кроме того, это постоянные улучшения, что для бизнеса дорого. Хорошо раскрывает эту тему статья Мартина Фаулера о расходах на архитектуру. Смею предположить, что вопрос того сколько бизнес хочет потратить ресурсов решение своих проблем в первую очередь он сам. И заказчик при этом не решает сколь-нибудь крупных своих проблем, то продать ему даже SOLID не выйдет.

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

Дисфункция #2: Быстрорастворимое проектирование aka Анемичная модель aka соглашательство

Очевидно, что некоторое сообщество программистов пытается нести в массы практики удешевляющие предметно-ориентированное проектирование, снижая затраты и применяя новые методики: RailwayProgramming, Pipelines, Анемичная модель. Классный подход, многие советуют, этому можно научить любого программиста: "вот тебе SeedWorks с интерфейсами, реализуй их и всем будет". И это работает! но это не DDD.

Вы не вполне поняли Эванса.

• Кто не хвалит Клопштока? Но станет ли его каждый читать? Нет. Мы хотим, чтобы нас меньше почитали, но зато прилежнее читали! (Лессинг).

Сейчас объясню.

Анемичная модель — это антипаттерн

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

Вот только модель сама по себе не важна! Тактические паттерны — не важны! Важны ограниченные контексты, единый язык, крупномасштабная структура. Именно поэтому к бизнес-сущности необходимо подойти с аналитической стороны, описывая корень агрегации, объекты-значения, бизнес-методы, а как следствие понять границы ограниченного контекста.

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

Но всё не могло закончиться бесславным концом DDD идеи.

Дисфункция No3 Жизнь после бизнес-объектов aka усложение инструментария.

Максим и Вагиб весной 2019 рассказывали нам о том как не приехали фичи F# в C#, О том что сделать правильно в F# модель проще, о том как в функциональщине не нарушить ООП. Теперь массы могли считать, что DDD не только не по карману заказывающим музыку, но и не для всех смертных, а только знающих функциональное программирование.

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

Конечно, нет никакого иначе. Все эти абстракции важны в переговорке на BrainSrorm'е, когда все должны понять всё предельно чётко. Или если вы найдёте менеджеров и аналитиков которые станут смотреть ваш код — единый язык (если код UL).

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

Что здесь совершенно отвратительно, так это простая человеческая природа отношения к достижениям — люди ценят такие достижения в себе, не придавая им формы и прикладного применения. И тут список может быть длинный. Эйнштейн дал нам СТО, ОТО, ФЭ, он отличный учёный, но спросите среднего человека о релятивисском движении, времени — не нужен ему Энштейн, но в "умном" разговоре можно было бы упоминуть, что всё относительно. Спросите человека о Фрейде, великолепном психологе, давшем серьёзное движение науке, использует ли этот человек психологию например для толкования вчерашнего кошмара — не будет, но упомянет когда-нибудь сексуальность и психологию масс. Маркс — тот кто сделал из социологии и истории науку, но ни кому нужен научный социализм, а вот про прогрессивный налог, честную демократию говорить могут все. Нет формы и у проблемно-ориентированного проектирования — Эрик Эванс открыл нам новые высоты, дав великолепное средство снижение сложности программного обеспечения, но якобы как применять DDD и что делать — не понятно, и вообще не совсем это подходит.

Не знаю как про остальное, но вот с предметно-ориентированным проектированием причины недопониманий понять можно.

Причины кризиса использования

Принципы предметно-ориентированного проектирования очень заманчивы, логичны и холистичны. Тут всё рядом — Agile, CI, SOLID, GRASP — всё лучшее что придумали разработчики. Однако, мало верить в DDD, или бизнес, или опыт. Многие люди из community, просто разработчики из интеграторов и аутсорсинг контор имеют отпечаток бизнес-ценностей в своей деятельности, и при всём желании не могут попробовать ведущие методики и практики, потому что цена этих проб и ошибок не входит в прайс — вполне материалистический финал.

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

Итог

DDD можно пробовать всегда, если вы описываете предметы реального мира. Этот подход можно применять и в PHP, и в VBA, и 1C (и разработчики применяют). Проблема применения подхода скорее в плоскости общения людей, а технологии скорее в помощь. Общайтесь, пробуйте, учите других! Прокачивайте Softskills, солидарность, единство целей. DDD — это всего лишь методика работы сплочённого коллектива.

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

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

P.S. Целью топика является приглашение к дискуссии. Нет никакой цели принизить заслуги любых членов DDD Community. С уважением отношусь ко всем представителям, что не снимает проблем развития.