Хабрахабр

[Из песочницы] Кризис DDD сообщества

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

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

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

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

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

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

Продвижение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»