Год назад Максим Аршинов (marshinov) выступил с докладом "Быстрорастворимое проектирование". Отличный доклад, харизматичный спикер, полезные материалы в конце. Этот доклад изменил моё понимание того что я делал — кто из нас не пытался интуитивно применить pipeline-архитектуру? А тут ещё элегантные решения, помноженные на DDD! С этого начался мой путь евангелиста предметно-ориентированного проектирования.
Скоро DotNext 2019 Moscow. Как всегда, ждём обзора новых фичей, обмена опытом, best practies, архитектурных решений — за это мы все и любим конференции. В списке докладов вокшоп "Блеск и нищета предметной модели", который обратил моё внимание. Цитата со страницы:
Фаулер и Эванс считают анемичную модель антипаттерном. Однако многие кодовые базы, с которыми доводилось работать спикеру, реализованы в стиле «анемичной» модели. Доклад посвящен сравнению сильных и слабых сторон обоих подходов и не очевидным деталям реализации модели предметной области в парадигме ООП и в функциональном стиле.
Сама постановка заставляет задуматься о том, что в развитии DDD движения наметился кризис. Небольшой разбор дисфункций использования и причинах подобных перекосов под катом.
Дисфункции использования предметно-ориентированного проектирования
У настоящей ситуации есть некоторое историческое развитие. Рассмотрим поэтапно как развивалась ситуация.
Продвижение
Максим, на мой взгляд — самый известный разработчик, состоящий в комьюнити, который много лет грамотно продвигал DDD, рассказывая о самом понятии, использовании. Честь ему за это и хвала! И я привожу в пример Аршинова, только потому, что считаю его лучшим на данный момент спикером дотнекста.
Дисфункция #1: Рентабельность
marshinov написал несколько статей на предмет стоимости внедрения практик DDD. Вывод простой — предметно-ориентированное проектирование стоит дорого. И суждения справедливы — сам Эванс в своей книге отмечает, что команда должны быть очень квалифицированной, а значит дорогой. Кроме того, это постоянные улучшения, что для бизнеса дорого. Хорошо раскрывает эту тему статья Мартина Фаулера о расходах на архитектуру. Смею предположить, что вопрос того сколько бизнес хочет потратить ресурсов на решение проблем, в первую очередь решает он сам. И заказчик при этом не решает сколь-нибудь крупных своих проблем, то продать ему даже SOLID не выйдет.
Очень важно понимать антагонизм бизнес-требований и архитектурных решений. Бизнесу необходимо наиболее дешёвое решение, которое закроет имеющиеся потребности (и лучше с первого раза и навсегда). Команды хотят делать инструменты и решения, которые наиболее правильно, быстро и красиво решают бизнес-задачи, но особенно задачу адаптивности к изменениям. Природа этих потребностей (по сути полярных противоречий) весьма диалектична, что в свою очередь означает, что нельзя получить реализацию сложных требований без проработки архитектуры, и нельзя стоить кондоминиумы вместо собачьей конуры. Нет, конечно, де-юре всё можно. Но, де-факто, высокие требования с одной стороны порождают соответствующие с другой. Как и патологическая слабость одной стороны ограничивает другую.
И вот, в попытке соответствовать бизнесу, образовалось вторая беда...
Дисфункция #2: Быстрорастворимое проектирование aka Анемичная модель aka соглашательство
Очевидно, что некоторое сообщество программистов пытается нести в массы практики удешевляющие предметно-ориентированное проектирование, снижая затраты и применяя новые методики: RailwayProgramming, Pipelines, Анемичная модель. Классный подход, многие советуют, этому можно научить любого программиста: "вот тебе SeedWorks с интерфейсами, реализуй их и всем будет". И это работает! но это не DDD.
Вы не вполне поняли Эванса.
- Кто не хвалит Клопштока? Но станет ли его каждый читать? Нет. Мы хотим, чтобы нас меньше почитали, но зато прилежнее читали! (Лессинг).
Сейчас объясню.
Анемичная модель — это антипаттерн
Дело в том, что в науке существует два метода исследования — описательный и аналитический (привет Адам Смит). Когда мы делаем Анемичную модель, мы просто описываем что видим, и живём с этим как есть. Это отражает бизнес и достаточно для реализации бизнес-возможности. Важный принцип, описанный Эвансом — не тратить ресурсы на идеальную систему, а смоделировать процесс так как он есть, а уже потом начинать глубокий рефакторинг. И в какой момент с Анемичной Моделью мы сможем перейти к глубокому рефакторингу? Предполагается ли вообще к нему приступить? Мне кажется, что ответ будет отрицательным, а модель тут осталась как атавизм.
Вот только модель сама по себе не важна! Тактические паттерны — не важны! Важны ограниченные контексты, единый язык, крупномасштабная структура. Именно поэтому к бизнес-сущности необходимо подойти с аналитической стороны, описывая корень агрегации, объекты-значения, бизнес-методы, а как следствие понять границы ограниченного контекста.
С одной стороны, анемичная модель решение дешёвое — это хорошо, ведь у начинающих программистов появиться понимание нового измерения в программировании — бизнес-объекты. Хорошо, да только если это план лишь первой итерации. Однако, занимая подобную позицию, делая работу не до конца, вы делаете плохо себе же. Нанимая каждый раз более слабого программиста, который может делать примерно то же самое что и вы копипастой, разве у вас найдётся аргумент для бизнеса поискать более сильного сотрудника?
Но всё не могло закончиться бесславным концом DDD идеи.
Дисфункция #3 Жизнь после бизнес-объектов 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 не трансформируют ещё в какую-то сторону в угоду удобности заказчикам и командам. Жду предстоящего доклада.
