Хабрахабр

[Из песочницы] Кризис 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.

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть