В Domain Driven Design есть много аспектов связанных с кодом, шаблонами и подходами к проектированию ПО. Это всё правильно и полезно, но вряд ли заказчик оценит то, что вы выделили функцию без side effects в Value Object и покрыли её тестами. Зато заказчику точно будут интересны и важны части DDD, которые связаны с поставкой продукта и коммуникацией.
Я собрал основные моменты, которые помогают программистам наладить общение с заказчиком и создать эффективную модель предметной области в коде:
- Единый язык (Ubiquitous Language) — название переменных, таблиц, названия кнопок в макетах, общение с заказчиком, всё это можно быть только на языке заказчика. Если у заказчика в бизнесе есть термин Агент, в коде он может называться только Agent. Если вы в коде начнёте называть его Customer, Contractor или еще как-то, то при общении с заказчиком будете называть его агентов своими «кастомерами». Со временем заказчику понадобится переводчик, чтобы понимать ваши термины, которыми вы называли его родные бизнес-сущности. Несколько примеров и описание проблемы можно посмотреть в статье Ubiquitous Language и Bounded Context в DDD.
- Модель предметной области (Domain Model) — из единого языка рождается модель предметной области, которая должна быть явно обозначена в коде. Это не анемичная модель, у неё есть поведение, как и у реальных объектов в бизнесе. Доменная модель выражает саму суть бизнеса, она должна быть собрана в одном месте, а не размазана по всему коду проекта.
- Углубленный рефакторинг (Refactoring toward deeper insight) — для создания модели предметной области в объектном анализе рекомендуют из общения с заказчиком, из ТЗ и других источников выделить существительные и глаголы, после чего сделать из них объекты и методы. Наивно полагать, что ваше знание предметной области будет достаточно хорошим, чтобы с первого раза постороить стоящую модель. С погружением в проект, с углублением вашего понимания бизнеса заказчика необходимо совершенствовать и модель.
- Дистиляция модели — для лучшей выразительности из Core Domain нужно убирать всё лишнее, например, выносить части не характерных только для вашей предметной области в Generic Subdomain. В конечном счёте Core Domain проекта является его конкурентным преимуществом, всё остальное можно взять в готовом виде, адаптировать из открытых источников или отдать на аутсорс.
- Ограниченные контекст (Bounded Context) — в подобластях одной отрасли (и одного бизнеса) могут складываться свои термины, даже для одних и тех же понятий. Их унификации — это компромисс. Если вы пойдете на него, то не получите выразительной модели ни в одной из подобластей. Обычно говорят, что модель применима в определенном контексте, причём внутри этого контекста термины модели имеют конкретный чёткий смысл.
Часть подходов, которые описаны в книгах можно попробовать только на проекте, который идет несколько лет. Часть подходов это не конкретные шаблоны, а скорее философия работы с требованиями, принципы выстраивания отношений между командой и заказчиками. Тема DDD довольно большая, но изучать её нужно обязательно. Могу рекомендовать две книги для погружения в тему:
- Классическая книга от Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software
- Более зрелая книга с большим количеством конкретных примеров наработанных сообществом Implementing Domain-Driven Design
Серия статей «Customer satisfaction для программистов»:
Александр, вопрос по поводу Ubiquitous Language.
ОтветитьУдалитьАгент/agent/contractor - это слишком простой пример.
Предметная область, допустим, техническое описание дороги. Или можно взять любую другую предметную область, не принципиально. Заказчик русскоязычный.
Полоса отвода, земляное полотно, проезжая часть, искусственные сооружения, дорожные инженерные устройства, путепроводы, виадуки, наземные пешеходные переходы, паромные переправы, подпорные стенки, снегозадерживающие переносные щиты, снегозащитные лесонасаждения...
Эти и сотни других объектов захотелось выделить как отдельные сущности со своими характеристиками, поведением и набором правил.
Что будет в коде? Можно ли будет говорить об Эвансовском Ubiquitous Language после перевода всех этих терминов? Не будет ли в данном случае русско-английский словарик тем самым мапинговым слоем, от которого Эванс и пытается избавиться? Как выкручиваться?
Если речь идет о строгом соответствии 1 к 1, то нарушений парадигмы нет. В конце концов, UL нужен, чтобы не возникало многозначностей. Для меня UL в первую очередь свредство быстро перейти к участку кода, описывающего соответствующую бизнес логику. И обратно - не лишне иметь возможность объяснить алгоритм эксперту на понятном ему языке. Придется, конечно, переводить на ходу с одного языка на другой, но в сравнении с другими проблемами, это мелочь. ...или радикально поступить...как 1С, методы и классы по-русски называеть :-)
ОтветитьУдалитьСоответствия 1 к 1 достичь чрезвычайно трудно.
ОтветитьУдалитьПрограммист-то на русском какой-либо из терминов может слышать первый раз в жизни. А тут ещё и словарик на каждое слово выдаёт набор синонимов. Из которых выбирается, как правило, не тот. Что характерно - и в обратную сторону тоже.
Когда у вас десятки и сотни таких специфичных терминов, то всё это становится реальной проблемой.
По поводу радикального результата - насколько я знаю, в мире .NET/C# так не принято. Коллеги затроллят. Индусам на поддержку такой код тоже уже не отдашь (что справедливо и для транслита). Плюс у решарпера то и дело воскресает RSRP-178492, после чего проект с русскими классами/методами может перестать строиться, выдавая неочевидную ошибку. Много проблем - склоняюсь, что это неудачное решение.
КМК нормального полноценного UL достичь в данном случае вообще не получится.
http://www.fulldress.ru/свадебные-платья-c-101
ОтветитьУдалитьСпасибо за обмен!
ОтветитьУдалитькрасивые вечерние платья
Спасибо за обмен!
ОтветитьУдалитьвечерние платья
Про радикальный подход это скорее шутка была.
ОтветитьУдалитьСловарь имелся в виду внутренний. То есть весь доменный лексикон ведется на русском, а для кода устанавливаете однозначный маппинг на англоязычные термины в рамках конкретного контекста.
Разумеется, придется выбрать какое-то одно значение из множества синонимов, которое выдаст обычный словарь, и где-то в документах этот выбор обозначить.
Например, для виадука http://multitran.ru предлагает следующие варианты:
(общ.) viaduct
(архит.) overpass
(мор.) causeway
(стр.) pipe bridge
Уже исходно видна небольшая контекстуализация.
Кстати, для всех терминов за исключением pipe bridge есть статья в википедии. Выбираете какой-то один, наибоолее характерный для ваших задач термин, заносите в глоссарий и используете в коде. А заказчика бьете по губам, если у них вдруг виадук становится эстакадой или мостом.
У нас, например, 'православным' DDD пока не пахнет. Agent, Partner и LegalEntity - всё об одном. Кое-где и Subagent встречается.
КМК нормального полноценного UL достичь в данном случае вообще не получится.свадебные платья для беременных
ОтветитьУдалитьЯ всегда стараюсь действовать в рамках 3-го варианта, т.к. явно описываются последствия для заказчика, идет попытка понять его решение. Первые два решения оставляют нас в однобокой и закрытой позиции.цветок девочки платья
ОтветитьУдалитьЭто, конечно, полу-шуточное объяснение принципа оценки проекта, но оно отлично показывает, что проекты никогда не идут по оптимистичному пути, всегда возникают проблемы и этот факт надо учитывать.вечерние платья в пол
ОтветитьУдалитьВремя перехода B → С (прозрачность высокая и доверие высокое) всегда разное, но по опыту могу сказать, что оно занимает обычно 2-4 месяца. Работа в квадрате С требует с нашей стороны значительных усилий, но за это мы получаем высокую лояльность заказчика. давно вечерние платья
ОтветитьУдалитьЕсть резонные вопросы, которые возникают после всех этих техник визуализации работы. Не много ли разных способов визуализации у нас получается? Нет ли среди них дублирования? короткие вечерние платья
ОтветитьУдалитьВ примерах мы говорим в основном о паре Requirements Model <-> Design Model, но все утвеждения справедливы для любой другой пары моделей. вечерние платья
ОтветитьУдалитьImpact Mapping является одной из активностей, которые сделают и заказчиков и разработчиков более счастливыми и эффективными. Ставьте правильные цели правильно! коктейльные платья
ОтветитьУдалитьТо что виадук можно перевести как viaduct - это моя оплошность, т.к. пример ничуть не лучше чем agent.
ОтветитьУдалитьНо смотрите, как ни крути, а в итоге всё равно получается именно то, от чего и предостерегает Александр:
Если вы в коде начнёте называть его Customer, Contractor или еще как-то, то при общении с заказчиком будете называть его агентов своими «кастомерами». Со временем заказчику понадобится переводчик, чтобы понимать ваши термины, которыми вы называли его родные бизнес-сущности.
А иначе можно было бы занести пару агент/customer в тот самый глоссарий и считать, что у нас есть UL. Но это так не работает.
А самое печальное в этой всей истории это то, что после перевода десятков подобных терминов, код перестают понимать не только заказчики, но и сами программисты. Обычный православный программист не сможет быстро прочитать программу, вместо этого он будет непрерывно ползать по глоссарию или вспоминать, что это за слово такое.
Хорошо одинэсникам)
А если не будет глоссария, сможет ли программист быстро прочитать программу?
ОтветитьУдалитьУ меня проблема, как правило, не в понимании ЧТО и КАК, а ЗАЧЕМ код это делает. Одно дело видеть мутный и длинный Transaction Script, другое - небельшой участок контекста, однозначно указывающий на use case. Как минимум, будет понятно, кого и о чем спросить, если что. Документировать систему проще, имея три основные координаты: BoundedContextName, Verb+Noun
UL, как мне кажется - годный инструмент, заставляющий разработчика мыслить так, чтобы в системе существовал только один способ получить желаемый результат.
В Implemening DDD, собственно, и говорится, что вот этот Strategic Design куда важнее, чем Tactical Patterns.
Спасибо за статью! Один минус - много терминов на английском у которых есть вполне адекватные аналоги на русском.
ОтветитьУдалитьСпасибо за статью! Один минус - много терминов на английском которые можно вполне адекватно обозначить на русском.
ОтветитьУдалитьАлександр, здравствуйте. А если не секрет, вы у стратоплана обучение не проходили? Хотелось бы услышать ваше мнение о них.
ОтветитьУдалитьНе согласен с выводом. Переговоры с заказчиком должен вести профессиональный переговорщик, а не программист (это не означает, что программист не должен присутствовать при этом вообще). Так как в этот момент заказчик ведет именно переговоры (пытается купить дешевле), а программист прикидывает технические решения. И да, в абсолютно идеальных условиях (которых не бывает в реальном физическом Мире) скорее всего эту задачу можно было бы решить за 4 дня. О чем программист честно и говорит, не подозревая о том, что только что продал себя очень дешево. Как то так.
ОтветитьУдалитьДак речь не идет про то, что продажу и переговоры ведет разработчик. Речь про то, что у разработчика в итоге спросят оценку по времени. В разных компаниях эту роль называют по разному: менеджер, директор, руководитель подразделения и т.п., но обязательно будет тот, кто скажет: Сколько времени займет фича?
ОтветитьУдалитьНет, обучение у них не проходил, поэтому ничего конкретного подсказать не смогу.
ОтветитьУдалитьНаверно, тут не очень хороший пример. Заказчик, жестко манипулируя, продавил программиста с месяца до 4-х дней. Вряд ли стоит винить программиста в этом случае. Тут как раз надо разбираться, почему у заказчика такое низкое доверие к первоначально озвученным срокам.
ОтветитьУдалитьА вы бы как поступали на месте заказчика? Представьте себе, что у вас в кармане лежит 100 тыс. рублей. Месяц разработки стоит 100 тыс. рублей. Вам нужно сделать новую фичу и скорее ее продать и при этом еще оплатить аренду квартиры и накормить семью. Разработчик говорит вам, что новая фича займет 1 месяц. Ваши действия? Согласиться? Попробовать продавать меньшие сроки и надеяться, что и за 4 дня успеют?
ОтветитьУдалитьЯ вполне понимаю, что продавливание сроков не добавляет очки в карму. Сам был разработчиком и даже в своей компании остаюсь разработчиком. Но жизнь устроена так, что сроки нужно сжимать, продукты выспускать быстрее и т.д.