Post #870

Сергей Баранов написал про DDD — Domain Driven Design. Предметно-ориентированное проектирование, как его по-русски называют. У меня есть по поводу DDD несколько инсайтов, накопилось материала на отдельный пост. 1) Аналитики не особо знают DDD, потому что DDD придумано как раз для ситуаций, когда разработчики работают без аналитиков. И нужно как-то понять, что там эти пользователи вообще хотят. А ничего нет — ни моделей процессов, ни требований, ни модели данных. Интересно тут то, что, в принципе, подошла бы любая техника выявления требований и описания предметной области: хоть модели БП, хоть Use Cases, хоть User Story Mapping. Было бы желание. Но желания в этом разбираться у программистов как раз обычно и нет, интереснее же писать код. То, что написанный код очень отдаленно соответствует предметной области, решает локальные проблемы и закрывает возможности для развития — выясняется сильно позже и больно бьет. Поэтому программисты придумали свой метод — запишем ровно то, что говорят пользователи (ubiquitous language), и будем делать в программе классы именно с такими именами — тогда произойдет магия и нас не заругают. 2) Программистам больше всего интересен слой логики. Вопрос хранения данных решает ORM, вопрос проектирования интерфейсов вообще оскорбителен — это дело дизайнеров же. Поэтому юскейсы и user story не заходят — они слишком много говорят о пользователях и сценариях их работы. Нам бы что-нибудь поближе к классам и их взаимодействию. То есть, это всё то же решение задачи — какие именно классы создать в объектно-ориентированной программе. Есть паттерны GoF, но они слишком низкоуровневые. Есть юскейсы — но они слишком высокуровневые, и непонятно, как перейти от них к классам. Знания предков, типа подхода Якобсона к отображению юскейсов на классы через Entity Object - Control Object - Boundary Object, оказались прочно забыты. Кроме того, программисты склонны упрощать юскейсы до операций CRUD, начисто отбрасывая всё рассмотрение деятельности пользователей (какая ещё деятельность, нипанятна). В Clean Architecture каждый use case — это отдельный класс, и они все живут в своем отдельном слое юскейсов. Вроде бы это как раз пересказ идей Якобсона про Control Object, но понятый не всеми. При этом часть логики живет в этом слое, а часть в Entity — опять непонятно, несмотря на название. DDD вводит свою терминологию (агрегаты, инварианты), и мы попадаем в ситуацию, когда несколько подходов говорят об одном и том же, но разными словами. 3) DDD упирает на generic domains: типовые домены, для которых вообще не нужно ничего разрабатывать, а взять готовое. Называются оценки 80/20 или даже 95/5 — мол, в вашем решении уникального-то всего 5%, на них и сосредоточьтесь, а остальное возьмите готовое. Здесь нужно быть втройне аккуратными, т.к. есть большой риск "выплеснуть с водой ребенка". Generic могут быть только низкоуровневые компоненты, типа аутентификации, хранения файлов, отрисовки интерфейсов и математических операций, или стандартизованные бизнес-функции, типа платежей, электронной подписи или обмена сообщениями. Всё, что несет чуть больше бизнесового контекста, попадает под два закона: 1. "Парадокс переиспользования": степень эффективности выполнения задачи компонентом в конкретном контексте обратно пропорциональна возможности переиспользования этого компонента (чем лучше работает, тем хуже возможность переиспользовать); 2. "Эффект фастфуда": чуть хуже + чуть хуже + чуть хуже + ... = полный провал. Если мы возьмем "95% не уникальных Generic функций", которые всего лишь чуть хуже, чем специализированные — на выходе получим неудобоваримое нечто. Поэтому мы не видим массово никаких "generic" библиотек или сервисов для бизнес-функций. Всё, что у нас есть — универсальные фреймворки, низкоуровневые библиотеки и готовые сервисы с типовой функциональностью. Может, вас и устроит типовое решение, но, как правило, лишь до какого-то момента. Итого, три инсайта про DDD: это для программистов без аналитиков, это для слоя логики, и со склонностью применять упрощенные решения там. А так-то дело хорошее.