Комментарии 39
Эмм, а по этой теме есть иллюстрирующие какие нибудь случаи?
Тут вина программиста, что побежал моделировать доменА почему программиста? Почему програмист должен
посмотреть в переписку с аналитиком и увидеть в девочке себя.Интересно есть ли какой-либо open-source проект где успешно используется DDD, чтобы посмотреть как оно правильно делается.
Банальный UI Kit, сделанный через MVC и аналоги (как тот же явовский Swing, но дофига их) — тоже DDD (доменом будет «взаимодействие с пользователем»), просто потому, что реализовать MVC не через model-first будет в чем-то сродни удалению гланд через задний проход.
Если говорить про фронтэнд, например, то большинство opinionated (т.е. навязывающих определенную модель и архитектуру) решений — вполне себе DDD. Тот же Redux, скажем.
Что если в домене используется некоторое общеупотребимое слово, например «свинья», как я должен понять что они используют это для обозначения способа построения воиск, а не как животное. Пример конечно утрирован, но думаю что понятно.
Аналитик вполне может считать, что по контексту вполне понятно, что имеется в виду. В школе же проходили.
А аналитики, конечно, не ошибаются, и не пропускают деталей, которые могут быть не очевидными программисту.
Аналитик приходит и говорит, что нужно научиться считать, сколько пирожков на всех противнях. А программист понимает, что неважно, противень это или какая-то другая посуда. Соответственно, на уровне кода уже закладывает не противни, а что-то более общее.
Вот MVC как раз часто реализуют от View… Буквально берут макеты, наброски UI и смотрят, что должно быть в модели
Если у нас есть предметная область от бизнеса — то там конечно модели должны вытекать из требований предметной области, но когда мы именно что проектируем библиотеку UI-компонент, то предметная область у нас сам UI.
Я про другие кейсы, когда бизнес доводит предметную область до разработки через макеты, а то и готовые UI. Ну, например, даёт форму сотрудника, где смешаны анкетные данные и список выполненных задач с оценкой и фактом, при том что ни один сотрудник даже при техническом наличии прав не редактирует и то, и другое. Грубо говоря, кадрам плевать на список, максимум им интересна агрегированная метрика точности оценок сотрудником своих задач за истекший квартал, чтобы премию выписать. А руководителю сотрудника нужно только его минимальная идентификация в виде, например, ФИО и точно он не будет их менять, если ФИО изменится или обнаружится ошибка.
А владелец продукта дал UI, где всё это в куче.
Имеено. Причём на словах DDD может активно "существовать", внедряться во всё новые слои и сервисы, просто потому что бизнес "мыслит формами и отчётами". При этом контексты не разделяет, сотрудник и там, и там один же человек, значит в форме должно быть и то, и другое.
Собственно на практике попыток внедрения DDD для меня самое сложное было заставить осознать бизнес, что у него есть разные контексты для сущностей реального мира и в некоторых контекстах они и не сущности вовсе, а какой-то снэпшот сущности на определенный момент. Осознать и выделить ресурсы на разбиение контекстов на уровне кода
Я пробовал смотреть разные примеры на Java/C#, но ничего толкового так и не нашел. В основном они очень примитивны и не покрывают даже минимальных самых частых проблем, про остальное и говорить не приходится.
По вашей ссылке автор ушел дальше абсолютного большинства, но только на первый взгляд. Куча инфраструктурного кода, за которой прячется сохрание 5 обьектов в базу и диспатч событий, кроме того, много спорных технических решений (кварц, голый sql, использование view для построения DTO, куча статических методов, дублирующийся код и так далее). Основная ценность — показано как использовать autofac.
Я буду признателен, если у вас есть другие примеры.
Можете посмотреть на плюралсайте лекции по DDD. Хориков, например, показывает неплохие уроки для чего нужен DDD и чем он полезен (для самых начинающих). Уже не помню кто еще.
Так что, навскидку, не помню, извините, не помогу. Если вспомню или наткнусь — поделюсь обязательно.
P.S. Некоторое дублирование кода неизбежно из за принципа… не знаю как это по русски, ограниченных контекстов (?). Это очень удобно, кстати, на больших проектах, которые пилятся большим количеством людей \ команд. Здорово окупается. Причем это удобно даже на относительно небольших проектах. Вообще, из моего опыта, DDD очень полезен начиная с некоторого размера проекта или команды, но надо осознавать его минусы и использовать без фанатичного следования «догме».
Голый sql допустим если использовать cqrs. Не помню используется ли он в том проекте на который я ссылался, но вроде должен был.
По ссылке что я привел — немного перебор, но, опять же, чтобы понять принцип — смотреть можно.
Но вот есть у нас UML class diagram, которая проста и распространена, т.е. многим известна и объяснять с нуля, что мы понимаем под вот этим кружочком, а что — под вот этой стрелочкой, не надо или надо гораздо реже; для её рисования есть куча софта на любой вкус.
В ней можно нарисовать собственно сущности, отношения с указанием множественности с каждой стороны (что иногда очень важно для понимания и вообще неочевидно до детального разбора с предметными специалистами), агрегаты (через, собственно, отношения агрегации, хотя я предпочитаю для наглядности рамочки нарисовать), наследование. Пихать туда все атрибуты и методы классов — ну да, извращение, это во всех отношениях удобнее в таблицы. Любые пояснения, которые очевидно в рамках нотации не изложить, просто пишутся текстом в выносных комментариях. Но верхнеуровневая картинка рисуется замечательно без изобретения велосипедов.
Возможно, Вы используете язык/парадигму программирования, которые действительно настолько далеки от «Java-образного понимания ООП», что конкретно в Вашем случае это вообще неудобно. Но львиная доля применений DDD, IMHO, — это корпоративные системы, а львиная доля корпоративных систем — это Java или C#, так что подобных проблем не возникает.
Так почему же «гарантированный провал»? Просто не панацея, не самоцель и не универсальный рецепт. Но вполне себе инструмент для работы.
Первый вопрос перед порывом нарисовать UML диаграмму должен быть "для кого я её собираюсь рисовать?"
Опередили :)
После 15 минут объяснения на первом примере — все умеют читать. Даже, не поверите, юристы, которые вообще по жизни самые большие приверженцы длинных и непонятных текстов вместо понятных картинок :)
Просто до всех быстро доходит, что писать текстом, скажем "к договору может быть заключено любле количество дополнительных соглашений или не заключено ни одного вовсе, но каждое дополнительное соглашение заключается только к одному договору; при этом само дополнительное соглашение является частным случаем договора, т.к. имеет те же атрибуты и внутреннюю структуру" — вместо того, чтобы нарисовать две стрелочки ассоциации и обобщения, в случае, когда таких сущностей у тебя несколько сотен, — вот это всё сомнительное удовольствие даже для юриста.
Можно, конечно, для этого не брать UML, а изобрести свою упрощённую нотацию. Но, во-первых, она не будет ничем лучше. Во-вторых, кто-то UML таки уже знает. В-третьих, стандартную диаграмму можно вставить в технический проект просто со ссылкой на стандарт, и не писать в нём предварительно описание изобретённого велосипеда.
А если смотрящий на диаграмму не знает разницы между стрелочками ассоциации и обобщения? Я вот наизусть не знаю, хотя изучал этот вопрос и сам диаграммы по стандарту рисовал (собственно для того и изучал). Если надо, то я хотя бы знаю где гуглить, а вот юрист, бухгалтер или менеджер вряд ли.
На моей памяти обычно все кивают, что понимают.
А потом на демонстрации нам говорят, что они вообще не то имели в виду.
Хотя на «картинках» было нарисовано то, что мы и реализовали.
Так вся мысль и была в том, что без фанатизма используемые элементы UML часто и являются самым простым способом объясниться. Или, по крайней мере, одним из самых простых способов.
Проблема в падении популярности UML, IMHO, в изначально завышенных ожиданиях от него. А когда тема с автоматической генерацией кода из UML не взлетела — это бросило тень на данную нотацию и как на инструмент более концептуального моделирования.
А если разработчики сами пилят модель по своему пониманию (пусть и проводя custdev с потенциальными клиентами — но клиенты при этом в команду проекта не вовлекаются), то вряд ли тут получится DDD в полном смысле этого слова.
А если проект «гос.», кстати, — то это скорее помеха и DDD, и UML и вообще всему разумному, доброму и вечному :) И попытки вставить диаграмму в документацию, оформленную по 19 и 34 ГОСТам, будут рассматривать как святотатство. Да и вообще ТЗ прошло через закупки и поэтому теперь высечено в граните и изменению не подлежит — хоть замоделируйся.
Как по мне, то проблема прежде всего в его сложности и избыточности для многих повседневных задач. Ну и инстрментарий так себе, по крайней мере тот, который я нашёл. Когда задать интерфейсы модели в коде быстрее чем нарисовать диаграмму, то только из под палки её можно рисовать.
Ответы собеседника могут быть как очень емкими, так и почти бесполезными. Строить наводящие вопросы без конкретного понимания «А что же я ищу» бесполезно.Частично решается выдачей листочков размером ~5x5см и карандаша для ответов. 1 вопрос — 1 ответ на таком листочке. Но тут правда начинаются трудности вида «умеет ли заказчик в принципе формулировать свои мысли на бумаге?». Ну помимо трудности с правильной формулировкой вопросов.
хорошо сформулированных идей\эвристик\дельных примеров страниц 20 от силы. Остальное занимают вдохновляшки и бесполезные листинги. В качестве проверки можете взять "Domain Driving Design" или "Рефактринг" Фаулера
От этой ошибки на уровне интуиции привиты те, кто писал на Prolog или Lisp. Это, кстати, одна из причин, почему это работает у Эванса, но не сработает у вас. В книге содержится достаточно много цельных переносимых идей, но за обилием призывашек и бесполезных примеров теряется суть многих из них, из-за чего внедрение проваливается.
Считаю, что некоторые читают подобные книги не правильно. Вместо того что бы пропустить через себя, применить критическое мышление, многие ищут мануала с серебряными пулями.
Вам дали молоток но не объяснили как пользоваться? Или научитесь через сбитые пальцы, или откажетесь когда пальцев не останется. А по-моему BBB — это мануал по тому как делать молотки (сорри, увлёкся метафорами).
5 способов провалить внедрение DDD