ддд с чего начать
От: okon  
Дата: 14.02.16 16:07
Оценка:
очень как-то сложно описывается,
например если посмотреть ту же вики то выделяются следующие элементы
Элементы DDD
3.1 Контекст
3.2 Сущность
3.3 Объект-значение
3.4 Сводный корень
3.5 Службы

Совсем не понятно зачем так раздроблено, чем плохо делать как обычно — модель данных, бизнес модель и рычажки методы для управления бизнес моделью. Вроде получаем те же плюшки в итоге — язык бизнес функций, я так понимаю основная затея ддд чтобы верхний уровень хорошо коррелировал с бизнес-требованиями.

Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re: ддд с чего начать
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 14.02.16 17:15
Оценка:
Здравствуйте, okon, Вы писали:

O>Может есть ддд описание где разжевывается не то как он устроен, а зачем он так устроен.


Без понятия, но знаю есть такая книжка: Предметно-ориентированное проектирование (DDD) Эванс Эрик
Re: ддд с чего начать
От: AndrewJD США  
Дата: 14.02.16 23:30
Оценка:
Здравствуйте, okon, Вы писали:

O>Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.


ИМХО, лучше забей на эту фигню и относись как к очередному базворду.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[2]: ддд с чего начать
От: okon  
Дата: 15.02.16 01:34
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, okon, Вы писали:


O>>Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.


AJD>ИМХО, лучше забей на эту фигню и относись как к очередному базворду.


Я так не могу взять и развидеть. Нужно убедиться что это не торт или наоборот что торт
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re: ддд с чего начать
От: Sinix  
Дата: 15.02.16 07:19
Оценка: 117 (4)
O>Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.
Как всегда, хочешь разобраться — читай первоисточник.
Тем более что книжка маленькая и читать стоит только первую часть, про "что такое DDD", а не вторую где на сам DDD забивают и начинают натягивать книгу на явапаттерны.

Если коротко, то domain-driven — это очень здравый и циничный подход к проектированию систем. Ещё раз: про проектирование, про "способ думать", не про реализацию. Т.е. как только очередной эксперт начинает рассказывать про репозитарий на уровне кода, потому что DDD, то можно доставить томик и ласково стучать по башке, предлагать освежить.

Вся движуха основана на очевидном для биз-аналитиков и абсолютно непонятном для программистов факте: предметная область заказчика и бизнес-процессы заказчика — две разные вещи. И, соответственно, работать с ними надо по-разному.


Плохая новость: предметная область в основном состоит из кучи очень неочевидных и неприятных ограничений. И, что самое обидное, от пожеланий заказчика они никак не зависят. Нулевых налогов, моментальных перевозок и хранения без усушки-утруски не бывает. В общем, бизнесу приходится с этим жить.

Хорошая новость: эти ограничения более-менее одинаковы для всех в одной и той же нише и практически не меняются годами. И изменения, раз уж происходят, обычно отражают реально изменившиеся обстоятельства — изменения законодательства, новый рынок / канал работы с контрагентами, новый вид услуг и тыды и тыпы.
Т.е. предметная область — это важно. Хорошее знание предметной области помогает на порядок снизить риски разработки за счёт разделения "так будет всегда" и "ну, мы хотим чтобы".


С бизнес-процессами заказчика всё наоборот: у каждого что-то своё, при отсутствии формализованных процессов систематизировать малореально, да и пока оформишь устраивающее всех ТЗ, всё десять раз успеет поменяться. Разумеется, это картина широкими мазками, в зависимости от заматерелости компании может быть расписано всё, вплоть до правил посещения туалетов.

Кэп: биз-процессы — это не менее важно. Проблема в том, что в них нет никакой системы и закономерности. Нет стабильно работающей схемы. _Текущий_ набор биз-процессов — это отражение _текущего_ положения дел на рынке и оставаться стабильным он будет в весьма ограниченном наборе случаев. Или когда бобик сдох, или когда внесение изменений обойдётся дороже, чем последствия политики "прём вперёд и пофиг на мины".

Вот и получается, что основная задача проектировщика — совместить несочетаемое: одновременно облегчить изменение кода, обеспечивающего биз-процессы и оставить платформу, которая даст возможность не строить всё с нуля при каждом изменении требований. Баланс между очень зависит от предметной области. Если все последствия заканчиваются на"не парь мозги, поправим завтра, если че", то можно расслабиться и не заморачиваться вылизыванием проектируемой системы. Если последствия наступают в виде бесплатного маски-шоу в офисе со всеми вытекающими — расслабляться лучше не надо.


С теорией всё, дальше в книге речь о нюансах применения на практике. Из них я бы обратил внимание на одну из самых вкусных штук в DDD — технику интервьюирования. Когда прям в процессе обсуждения биз-требований итеративно строится модель предметной области и проверяется через описание биз-процессов в терминах этой модели (ну и наоборот, что не менее важно).
Чтоб понять о чём идёт речь — гл 16 Building Domain Knowledge вот тут (можно не регистрироваться, вход ч/з гугл-твиттер-фб).
Re: ддд с чего начать
От: Baudolino  
Дата: 15.02.16 11:06
Оценка: 174 (5) +1
По своему опыту могу сказать, что DDD стоит трактовать не узко, как реализацию набора классов, моделирующих и состояние, и поведение предметной области (что заставляет архитекторов и разработчиков изначально втискиваться в рамки платформы и терминологии, в которой инкапсуляция — это строго классы, а не, например, пакеты и компоненты), а как подход к проектированию, опирающийся на предметную область, описанную единым языком (ubiquitous language). Этот подход неразрывно связан с построением информационной архитектуры в рамках проектирования UX и выглядит примерно так:

1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).
Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
На выходе получаете список потребностей заказчика в свободной форме.

2. Аналитический этап:
а) Из предложений в тексте списка потребностей выбираются существительные (подлежащие, дополнения и обстоятельства) и фиксируются в качестве сущностей домена.
б) Анализируются определения, связанные с выделенными сущностями: если определение приводит к полиморфизму, то это скорее всего новый класс, иначе — одно из значений какого-то атрибута.
в) Анализируются и классифицируются подлежащие и обстоятельства: они могут описывать операции над сущностями и связи между ними.
г) Модель, полученная по итогам анализа текста, пересматривается с учетом исключительных ситуаций и возможно пропущенных сценариев: проверяются достоверность полученной иерархии классов, возможные значения атрибутов, мощности связей и т.п. Вносятся необходимые уточнения.

На выходе получаете структурированный документ — информационную архитектуру. Информационная архитектура будет определять 80% вашей доменной модели.

3. Следующий этап — проектирование карты достижения целей пользователя (Customer Journey Map).
На этом этапе ваша задача определить кратчайший путь движения пользователя от возникновения потребности до её реализации с помощью разрабатываемой системы.
Именно здесь выделяются первые интерфейсы (без их визуализации, как сущности) и у вас появляется возможность уточнить информационную архитектуру.
На выходе у вас получается целостное описание работы приложения без иллюстраций, которое можно брать за основу для руководства пользователя.
Полученный таким образом CJM используется далее прим пользовательском тестировании приложения в качестве шаблона, который заполняется результатами тестирования для последующего улучшения интерфейса.
Кроме того, CJM фактически является готовым перечислением интеграционных тестов, которые вы можете написать (и тут DDD логичным образом перетекает в TDD).

4. Итак, поскольку вы уже полностью представляете себе, как должно работать приложение с точки зрения внешнего наблюдателя, можно приступать, к проектированию системной архитектуры и дизайну внешнего вида интерфейса: здесь в рамках DDD вам нужно просто спроецировать информационную архитектуру на платформу реализации, в том числе выбрать подходящие типы данных, механизмы реализации связей между сущностями и т.п. Здесь вы в последний раз уточните домен, выявив недостающие ограничения и взаимосвязи с помощью формального анализа логики приложения (многие ранее не учтенные особенности выявляются блок-схемами алгоритмов реализации). Важно, что вы не обязаны следовать здесь определенному архитектурному паттерну и впихивать невпихуемое в один класс, потому что кто-то сказал, что DDD — это rich model. Это не так: практически в каждом языке общего назначения инкапсуляция реализуется не только через классы, но и через их связные ансамбли с ограниченной областью видимости деталей внутреннего взаимодействия (пакеты и компоненты, пространства имен и т.п.), соответственно, сущность доменной модели может быть представлена разными способами, выбор которых зависит от особенностей вашей модели, выбранной платформы и т.п. Для вас важнее будет не конкретный выбор паттерна, а обеспечение устойчивости архитектуры к изменениям за счет точного описания сущностей предметной области, приближенного к бизнесу, и за счет снижения связности, которое вы можете обеспечить, адаптируя доменную модель к нуждам конкретных компонентов с помощью различных паттернов (DTO, фасады и т.п.).
Re[2]: ддд с чего начать
От: okon  
Дата: 18.02.16 16:48
Оценка:
Здравствуйте, Baudolino, Вы писали:

Подробно. Но сложно

B>По своему опыту могу сказать, что DDD стоит трактовать не узко, как реализацию набора классов, моделирующих и состояние, и поведение предметной области (что заставляет архитекторов и разработчиков изначально втискиваться в рамки платформы и терминологии, в которой инкапсуляция — это строго классы, а не, например, пакеты и компоненты), а как подход к проектированию, опирающийся на предметную область, описанную единым языком (ubiquitous language). Этот подход неразрывно связан с построением информационной архитектуры в рамках проектирования UX и выглядит примерно так:


B>1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).

B>Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
B>На выходе получаете список потребностей заказчика в свободной форме.

Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать, а это необходимо если проект не на 1 день, а большой. Т.е. этот этап идеален но не очень практичен например на больших проектах размером в 1 чел.год .


B>2. Аналитический этап:

B>а) Из предложений в тексте списка потребностей выбираются существительные (подлежащие, дополнения и обстоятельства) и фиксируются в качестве сущностей домена.

B>б) Анализируются определения, связанные с выделенными сущностями: если определение приводит к полиморфизму, то это скорее всего новый класс, иначе — одно из значений какого-то атрибута.

B>в) Анализируются и классифицируются подлежащие и обстоятельства: они могут описывать операции над сущностями и связи между ними.
B>г) Модель, полученная по итогам анализа текста, пересматривается с учетом исключительных ситуаций и возможно пропущенных сценариев: проверяются достоверность полученной иерархии классов, возможные значения атрибутов, мощности связей и т.п. Вносятся необходимые уточнения.

Как правило после интервью остается больше вопросов и ответы уже ищутся по ходу реализации, т.к. не понятно что спрашивать и только наверное 20% сущностей можно услышать из интервью , остальные выявляются уже по ходу.
Не то чтоб заказчик специально вам о них не говорит, просто многие вещи о которых он не скажет для него достаточно очевидны и он не заостряет на них внимание.


B>На выходе получаете структурированный документ — информационную архитектуру. Информационная архитектура будет определять 80% вашей доменной модели.


B>3. Следующий этап — проектирование карты достижения целей пользователя (Customer Journey Map).

B>На этом этапе ваша задача определить кратчайший путь движения пользователя от возникновения потребности до её реализации с помощью разрабатываемой системы.
B>Именно здесь выделяются первые интерфейсы (без их визуализации, как сущности) и у вас появляется возможность уточнить информационную архитектуру.
B>На выходе у вас получается целостное описание работы приложения без иллюстраций, которое можно брать за основу для руководства пользователя.
B>Полученный таким образом CJM используется далее прим пользовательском тестировании приложения в качестве шаблона, который заполняется результатами тестирования для последующего улучшения интерфейса.
B>Кроме того, CJM фактически является готовым перечислением интеграционных тестов, которые вы можете написать (и тут DDD логичным образом перетекает в TDD).



B>4. Итак, поскольку вы уже полностью представляете себе, как должно работать приложение с точки зрения внешнего наблюдателя, можно приступать, к проектированию системной архитектуры и дизайну внешнего вида интерфейса: здесь в рамках DDD вам нужно просто спроецировать информационную архитектуру на платформу реализации, в том числе выбрать подходящие типы данных, механизмы реализации связей между сущностями и т.п. Здесь вы в последний раз уточните домен, выявив недостающие ограничения и взаимосвязи с помощью формального анализа логики приложения (многие ранее не учтенные особенности выявляются блок-схемами алгоритмов реализации). Важно, что вы не обязаны следовать здесь определенному архитектурному паттерну и впихивать невпихуемое в один класс, потому что кто-то сказал, что DDD — это rich model. Это не так: практически в каждом языке общего назначения инкапсуляция реализуется не только через классы, но и через их связные ансамбли с ограниченной областью видимости деталей внутреннего взаимодействия (пакеты и компоненты, пространства имен и т.п.), соответственно, сущность доменной модели может быть представлена разными способами, выбор которых зависит от особенностей вашей модели, выбранной платформы и т.п. Для вас важнее будет не конкретный выбор паттерна, а обеспечение устойчивости архитектуры к изменениям за счет точного описания сущностей предметной области, приближенного к бизнесу, и за счет снижения связности, которое вы можете обеспечить, адаптируя доменную модель к нуждам конкретных компонентов с помощью различных паттернов (DTO, фасады и т.п.).



Получается что пока не понятно что делать нет возможности приступить к разработке, это не практично.

Приходилось сталкиваться с проектами как сопровождения так и разработки полностью с нуля , никогда не бывает что сразу все понятно, но разработка как правило начинается с некого прототипа, который как правило не похож на финальное решение, которое получилось бы если сразу все знать и понимать. Но на понимание нужно много времени особенно не очень тривиальной предметной области. Ну представьте что вот перед вами задача — написать 1С, вот детальные требования заказчика ( представим и такой идеальный вариант ) , сколько времени вам потребуется как архитектору чтобы понять все это провести пункты которые вы описали п.2 п.3 п.4 — на это никто времени не даст.

Собственно меня ДДД и привлекает тем что язык описания как бы коррелирует с бизнесом и бизнес может впринципе сам конструировать реализацию или по крайней мере понимать ее.
Когда все сразу известно то и конструктор не нужен, написал и все. Поэтому мне кажется ДДД все таки должна дружить с гибкими методами разработки когда в начале совсем практически не понятно что будет в конце тоннеля.
Поэтому хотелось бы пример практики ДДД, но который можно использовать в 80% случаев а не в 20%
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[3]: ддд с чего начать
От: Baudolino  
Дата: 18.02.16 18:09
Оценка: +2
Здравствуйте, okon, Вы писали:

B>>1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).

B>>Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
B>>На выходе получаете список потребностей заказчика в свободной форме.

O>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать

Вот тут как раз не надо долго! Надо кратко и с точки зрения бизнеса. Заказчик не должен продумывать, как все должно работать, — это задача команды разработчиков.
Пример правильно записанной хотелки: "Я банкир, я хочу, чтобы мои клиенты могли переводить друг другу деньги с помощью мобильного приложения, потому что это повысит привлекательность моих банковских продуктов."
Всё. Как именно это будет происходить — ваша задача предложить.
Или: "Я специалист по продажам, мне нужно знать, какие постоянные клиенты давно ничего не заказывали, чтобы предложить им сделать новый заказ".
Обратите внимание на вторую часть хотелки — конечная бизнес-цель. Ее знать не обязательно, но полезно, поскольку может помочь связать разные требования воедино (во втором примере можно сразу автоматизировать подготовку коммерческого предложения клиенту). Никаких форм, кнопок, серверов здесь не должно упоминаться. Исключение: у заказчика есть пользователи, уже привыкшие работать с определенным интерфейсом/в рамках определенного процесса — это знание пригодится, хотя и не должно являться требованием скопировать существующее решение.

O>Как правило после интервью остается больше вопросов и ответы уже ищутся по ходу реализации, т.к. не понятно что спрашивать

Спрашивать всегда нужно три вещи:
1. Каковы бизнес-цели заказчика? ("Я владелец фирмы-дистрибьютора элитной сантехники, хочу продавать свои товары через интернет. Хочу чтобы сайтом пользовались и дизайнеры интерьеров, получая информацию о новых сериях.")
2. Кто пользователи? (количество, демография, их связь с интервьюируемым)
3. Каковы их цели? ("Пользователь должен иметь возможность подобрать товар, подходящий к дизайну его ванной комнаты по стилю и цвету.")

O>Получается что пока не понятно что делать нет возможности приступить к разработке, это не практично.

Как вы себе представляете разработку в условиях, когда не понятно, что делать?
Если серьезно, хороший анализ экономит массу времени и, в конечном счете, уйму денег. Лишняя неделя на подумать спасет вас от пары месяцев переделок и вероятных срывов сроков.

O>Приходилось сталкиваться с проектами как сопровождения так и разработки полностью с нуля , никогда не бывает что сразу все понятно, но разработка как правило начинается с некого прототипа, который как правило не похож на финальное решение, которое получилось бы если сразу все знать и понимать.

Согласен, никогда не бывает так, что вся картинка складывается сразу. Даже если вы получили всю необходимую информацию и быстро спроектировали систему по состоянию дел в момент времени Т, через полгода бизнес заказчика изменится и требования вместе с ним. Но DDD не противоречит итеративной разработке — это аналитический подход, который защищает вас от ненужных ошибок, а не от вынужденных переделок.

O>Собственно меня ДДД и привлекает тем что язык описания как бы коррелирует с бизнесом и бизнес может в принципе сам конструировать реализацию или по крайней мере понимать ее.

В идеальном мире да, но наша профессия существует благодаря тому, что мы дополняем описание бизнеса спецификой реализации на основе разных профессиональных знаний: юзабилити, выбор алгоритмов исходя из их производительности и т.п. Это то, чего бизнес не сможет делать самостоятельно без посторонней помощи никогда.

O>Поэтому мне кажется ДДД все таки должна дружить с гибкими методами разработки когда в начале совсем практически не понятно что будет в конце тоннеля.

Ещё как дружит. Все что я описал, применимо к отдельным фичам — не обязательно прописывать все приложение сразу. Например, если вы делаете интернет-магазин, вы вероятно потратите немало времени, чтобы понять всю специфику каталога товаров вашего заказчика. Но уже в первом спринте вы сможете набросать прототип с корзиной и регистрацией пользователей, который отображает товары простым списком без структуры, и описывает их одним названием, без фото, характеристик и прочего.
Re[4]: ддд с чего начать
От: okon  
Дата: 18.02.16 19:29
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, okon, Вы писали:


B>>>1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).

B>>>Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
B>>>На выходе получаете список потребностей заказчика в свободной форме.

O>>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать

B>Вот тут как раз не надо долго! Надо кратко и с точки зрения бизнеса. Заказчик не должен продумывать, как все должно работать, — это задача команды разработчиков.
B>Пример правильно записанной хотелки: "Я банкир, я хочу, чтобы мои клиенты могли переводить друг другу деньги с помощью мобильного приложения, потому что это повысит привлекательность моих банковских продуктов."
B>Всё. Как именно это будет происходить — ваша задача предложить.

B>Или: "Я специалист по продажам, мне нужно знать, какие постоянные клиенты давно ничего не заказывали, чтобы предложить им сделать новый заказ".

B>Обратите внимание на вторую часть хотелки — конечная бизнес-цель. Ее знать не обязательно, но полезно, поскольку может помочь связать разные требования воедино (во втором примере можно сразу автоматизировать подготовку коммерческого предложения клиенту). Никаких форм, кнопок, серверов здесь не должно упоминаться. Исключение: у заказчика есть пользователи, уже привыкшие работать с определенным интерфейсом/в рамках определенного процесса — это знание пригодится, хотя и не должно являться требованием скопировать существующее решение.

O>>Как правило после интервью остается больше вопросов и ответы уже ищутся по ходу реализации, т.к. не понятно что спрашивать

B>Спрашивать всегда нужно три вещи:
B>1. Каковы бизнес-цели заказчика? ("Я владелец фирмы-дистрибьютора элитной сантехники, хочу продавать свои товары через интернет. Хочу чтобы сайтом пользовались и дизайнеры интерьеров, получая информацию о новых сериях.")
B>2. Кто пользователи? (количество, демография, их связь с интервьюируемым)
B>3. Каковы их цели? ("Пользователь должен иметь возможность подобрать товар, подходящий к дизайну его ванной комнаты по стилю и цвету.")



Мне кажется это совсем не техническая задача, это маркетологи, бизнес-аналитики, юристы должны придумать бизнес продукт, т.е. как это будет работать с т.з. бизнеса , выделить в этом части которые нуждаются в ПО, и привлечь на эти работы уже разработчиков. Например чтобы переводить друг другу деньги с помощью мобильного там от ПО наверное 10% работы. Одна из сложностей например это законодательство, можно написать классное с технической точки зрения приложение, но им нельзя будет пользоваться , например оно будет противоречить какому-либо закону. ЦБ, налоговая, банковская сфера , все это нужно хорошо понимать чтобы придумать продукт такой как перевод друг другу денег. И разработчики тут бессильны им нужно чтобы кто-то это все объяснил, а понять это достаточно сложно не каждому дано 2-3 образования иметь ( не в смысле корочик или дипломы а чтобы это все оставалось в светлой голове )






O>>Получается что пока не понятно что делать нет возможности приступить к разработке, это не практично.

B>Как вы себе представляете разработку в условиях, когда не понятно, что делать?
B>Если серьезно, хороший анализ экономит массу времени и, в конечном счете, уйму денег. Лишняя неделя на подумать спасет вас от пары месяцев переделок и вероятных срывов сроков.
Анализ это дорого, аналитики очень дорогие и показывает практика могут думать бесконечно, причем пока они думают меняется законодательство , технологии и к тому времени уже пора думать заново.
Поэтому реальность диктует гибкие методологии где слона едять очень маленькими порциями ( живут сегодняшним днем ) и каждый день делают шаг не к какой-то цели которая была изначально а постоянно корректируя курс.
Когда совсем ничего не понятно, тогда конечно писать нечего, но когда немного схвачено и кажется что что-то понятно уже можно это сделать и показать как 1 фича продукта.


O>>Приходилось сталкиваться с проектами как сопровождения так и разработки полностью с нуля , никогда не бывает что сразу все понятно, но разработка как правило начинается с некого прототипа, который как правило не похож на финальное решение, которое получилось бы если сразу все знать и понимать.

B>Согласен, никогда не бывает так, что вся картинка складывается сразу. Даже если вы получили всю необходимую информацию и быстро спроектировали систему по состоянию дел в момент времени Т, через полгода бизнес заказчика изменится и требования вместе с ним. Но DDD не противоречит итеративной разработке — это аналитический подход, который защищает вас от ненужных ошибок, а не от вынужденных переделок.

B>Ещё как дружит. Все что я описал, применимо к отдельным фичам — не обязательно прописывать все приложение сразу. Например, если вы делаете интернет-магазин, вы вероятно потратите немало времени, чтобы понять всю специфику каталога товаров вашего заказчика. Но уже в первом спринте вы сможете набросать прототип с корзиной и регистрацией пользователей, который отображает товары простым списком без структуры, и описывает их одним названием, без фото, характеристик и прочего.


Вот и интересно было бы именно жизненный пример, допустим с тем же интернет магазином, изначально ничего не понятно, но понятно что да есть какая-то витрина и это можно покупать. Вот как бы вы начали писать код в рамках ДДД зная только это и как бы трансформировался когда некоторые детали начинали проясняться , а возможно и менялись бы требования.
Интересует именно как бы выглядел код на разных этапах
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[3]: ддд с чего начать
От: Sinix  
Дата: 19.02.16 06:16
Оценка: 5 (2) +2
Здравствуйте, okon, Вы писали:

O>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать, а это необходимо если проект не на 1 день, а большой. Т.е. этот этап идеален но не очень практичен например на больших проектах размером в 1 чел.год .


Baudolino уже всё неаписал, дополню: DDD работает, если вся команда готова разобраться в предметной области хотя бы настолько, чтобы хотя бы понимать, о чём говорит заказчик.
Если начинаются отмазки в духе "некогда думать, программисты простаивают", "разбираться — это работа аналитика, а не программиста" и тыды — DDD можно выбрасывать. И, за редким исключением, сам проект тоже.

Без обид, не девяностые как бы. Программисты-кодеры "моя писать код" уже никому не нужны. Нужны разработчики. Разница — тынц. Или, в одно предложение: разработчик — специалист, способный самостоятельно довести идею до реализации в состоянии, готовом для отправки клиенту.

В общем, не в том направлении думаете. DDD не создаст за вас нормальный рабочий процесс.
А вот наоборот — сколько угодно. В командах с сильными биз-аналитиками практически всегда используется нечто DDD-style, иначе аналитик и остальная команда просто не смогут нормально общаться.
Re[4]: ддд с чего начать
От: okon  
Дата: 19.02.16 07:47
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, okon, Вы писали:


O>>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать, а это необходимо если проект не на 1 день, а большой. Т.е. этот этап идеален но не очень практичен например на больших проектах размером в 1 чел.год .


S>Baudolino уже всё неаписал, дополню: DDD работает, если вся команда готова разобраться в предметной области хотя бы настолько, чтобы хотя бы понимать, о чём говорит заказчик.

S>Если начинаются отмазки в духе "некогда думать, программисты простаивают", "разбираться — это работа аналитика, а не программиста" и тыды — DDD можно выбрасывать. И, за редким исключением, сам проект тоже.

Ну допустим понимание терминов заказчика можно преодолеть, особенно если они не все сразу появляются. Но как быть с тем сразу не понятно каким будет софт через год, не известно какие клиенты будут работать, какие у них будут ограничения, т.е. дизайн нужно начинать делать очень гибким c минимальным пониманием в начале.
Т.е. интересна эволюция разработки ДДД дизайна от простого к сложному так скажем. Хотелось бы такой пример именно поглядеть ( может есть на какойнить проект известный c этим подходом где это видно по истории коммитов )
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[5]: ддд с чего начать
От: Sinix  
Дата: 19.02.16 10:21
Оценка: 18 (1) +1
Здравствуйте, okon, Вы писали:

O>Ну допустим понимание терминов заказчика можно преодолеть, особенно если они не все сразу появляются.

Снова — не в ту сторону думаете

Речь не о понимании терминов. Речь о построении боль-менее рабочей ментальной модели предметной области.
Рабочей — не в смысле всемогутора, а в смысле, что она применяется и понимается всеми участниками процесса разработки, от представителя заказчика и до QA.

Речь о самих терминах, о списке ключевых сущностей и связях между ними. Не надо начинать с фаулеробреда аля "сотрудник — это сущность с атрибутами ФИО...". Вас интересует что-то вида "сотрудник — это физлицо, принятое на работу в конкретной организации" — увидели, что у нас как бы между прочим появляется как минимум три связанных понятия? И, что самое важное, они никуда не денутся хоть через год, хоть через десять и на это можно смело закладываться при дальнейшем анализе.

О ограничениях, наложенных на сами сущности. Они могут как очевидными (возраст физлица не должен быть отрицательным), так и связанными с нюансами предметной области. Например, нет никакого смысла принимать сотрудника в ту же организацию дважды. Не, человек может занимать одновременно несколько разных должностей, но это будет ещё одна отдельная сущность, которую нет никакого смысла мапить на самого сотрудника.

Ну и наконец, не надо забывать о языке, т.е. о использовании модели для описания бизнес-требований. Это безумно важная штука, т.к. она позволяет проводить перекрёстную проверку. Одновременно проверяется и корректность модели — если что-то упущено, то оно сразу видно — и корректность самих бизнес-требований. Если их нельзя описать языком модели, то, вполне возможно, мы хотим чего-то странного. Не, идея дарить приятную мелочь при увольнении конечно классная, но вы уверены, что в анкете сотрудника должно быть поле "любимый сорт мороженого"?

В общем, всё вышеперечисленное не является чем-то новым и неявно используется в любом из проектов. Всё, что даёт DDD — это способ формализовать неявное знание и позволить его использовать всем, а не только экспертам по предметной области.



O>Но как быть с тем сразу не понятно каким будет софт через год, не известно какие клиенты будут работать, какие у них будут ограничения, т.е. дизайн нужно начинать делать очень гибким c минимальным пониманием в начале.


А это не ответственность DDD. Он вообще ортогонален применяемой методологии разработки, его роль заканчивается на анализе и отборе требований. Что с ними дальше делать — ваш выбор.

Можно начать с реализации всех сущностей и дальше медленно и планомерно обвешивать их фичами, эдакий злой водопад.
Можно сделать так, как предлагает Baudolino — вчерновую накидать модель, нарисовать по ней основные сценарии и объединять близкие сценарии в одну итерацию.

Можно наконец сделать тру-аджил и строить модель прямо по ходу дела, одновременно с написанием кода. Разумеется, для такого экстрима нужен очень небольшой проект (или разбиение на минипроекты), очень сработанная команда, и очень хороший аналитик, который знает предметную область от и до. Иначе постоянные переделки из-за ошибок в выборе "что важно а что нет" убивают весь кайф.

В общем всё зависит от проекта и от стиля работы команды.
Re[6]: ддд с чего начать
От: okon  
Дата: 19.02.16 11:39
Оценка:
nЗдравствуйте, Sinix, Вы писали:

S>Здравствуйте, okon, Вы писали:


O>>Ну допустим понимание терминов заказчика можно преодолеть, особенно если они не все сразу появляются.

S>Снова — не в ту сторону думаете

S>Речь не о понимании терминов. Речь о построении боль-менее рабочей ментальной модели предметной области.

S>Рабочей — не в смысле всемогутора, а в смысле, что она применяется и понимается всеми участниками процесса разработки, от представителя заказчика и до QA.

S>Речь о самих терминах, о списке ключевых сущностей и связях между ними. Не надо начинать с фаулеробреда аля "сотрудник — это сущность с атрибутами ФИО...". Вас интересует что-то вида "сотрудник — это физлицо, принятое на работу в конкретной организации" — увидели, что у нас как бы между прочим появляется как минимум три связанных понятия? И, что самое важное, они никуда не денутся хоть через год, хоть через десять и на это можно смело закладываться при дальнейшем анализе.


Допустим , но в конечном счете даже на этом этапе заказчику этот анализ и разговор на его языке не нужен.
Ему нужен программный продукт, в вот собственно продукт получается когда мы написали N cтрок кода. Как я понимаю ддд говорит не только о том что вникайте в предметную область, разговаривайте больше и понимайте, он говори также как строить код.
Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.

Вот как поговорить с заказчиком в рамках работы по ддд мы уже обсудили, хотелось бы понимания а что собственно дальше как это превращается в код, который я так понимаю должен на верхнем уровне быть написан на языке заказчика и легко отражаться на требования.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[7]: ддд с чего начать
От: Sinix  
Дата: 19.02.16 13:13
Оценка: +1
Здравствуйте, okon, Вы писали:

O>Допустим , но в конечном счете даже на этом этапе заказчику этот анализ и разговор на его языке не нужен.

В смысле?
Заказчик уже отвалил бабки, не подписав ТЗ? Или ТЗ какой-то другой магией составляется, без тотального выноса мозга заказчику?
Ну а если есть ТЗ — то собственно в чём вопрос-то?
Вы уже собрали всё, что вам нужно, вопрос только в том, как структурировать.


O>Ему нужен программный продукт, в вот собственно продукт получается когда мы написали N cтрок кода.

Нафига заказчику код? Бизнес всегда покупает не продукт, а решение своих проблем. Собственно про это ТЗ и пишется.


O>Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.

Вот эту часть сразу выкинуть. Книга писалась в 2003 году емнип. В то время Эванс дружил с яваводами и регулярно выступал на фаулероведческих конференциях. Сами прикинете, насколько оно сейчас актуально?


O>Вот как поговорить с заказчиком в рамках работы по ддд мы уже обсудили, хотелось бы понимания а что собственно дальше как это превращается в код, который я так понимаю должен на верхнем уровне быть написан на языке заказчика и легко отражаться на требования.

Так же, как и всегда.
У вас есть часть, которая практически гарантированно не меняется — модель предметной области.
У вас есть структурированные сторилайны. Чего ещё может понадобиться?

Как по мне, так это идеальнейшие условия для.
Re[8]: ддд с чего начать
От: LeonidV Ниоткуда http://vygovskiy.com
Дата: 19.02.16 21:14
Оценка:
Здравствуйте, Sinix, Вы писали:
O>>Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.
Вот как раз это не потеряло своей актуальности. Что-то, конечно устарело или перодилось в oninon architecture или CQRS.
http://jvmmemory.com — простой способ настройки JVM
Re[8]: ддд с чего начать
От: okon  
Дата: 20.02.16 01:45
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, okon, Вы писали:


O>>Допустим , но в конечном счете даже на этом этапе заказчику этот анализ и разговор на его языке не нужен.

S>В смысле?
S>Заказчик уже отвалил бабки, не подписав ТЗ? Или ТЗ какой-то другой магией составляется, без тотального выноса мозга заказчику?
S>Ну а если есть ТЗ — то собственно в чём вопрос-то?
S>Вы уже собрали всё, что вам нужно, вопрос только в том, как структурировать.

мне пока не повезло увидеть ТЗ такое чтоб вот сделал как в нем написано и все были довольны.
Да и какое ТЗ может быть в agile ? Только очень краткое.

O>>Ему нужен программный продукт, в вот собственно продукт получается когда мы написали N cтрок кода.

S>Нафига заказчику код? Бизнес всегда покупает не продукт, а решение своих проблем. Собственно про это ТЗ и пишется.
Ну да , а для решения проблемы нужен продукт, а продукт чтобы появился нужно написать код.


O>>Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.

S>Вот эту часть сразу выкинуть. Книга писалась в 2003 году емнип. В то время Эванс дружил с яваводами и регулярно выступал на фаулероведческих конференциях. Сами прикинете, насколько оно сейчас актуально?
Пока сложно прикинуть, ибо надо понимать зачем эти вещи введены и что они значат, почему не хватает обычного деления на Data,Business

O>>Вот как поговорить с заказчиком в рамках работы по ддд мы уже обсудили, хотелось бы понимания а что собственно дальше как это превращается в код, который я так понимаю должен на верхнем уровне быть написан на языке заказчика и легко отражаться на требования.

S>Так же, как и всегда.
S>У вас есть часть, которая практически гарантированно не меняется — модель предметной области.
А зачем тут новые 3 слова ддд, чем это не вписывается в практику 90х — каждая сущность класс и в бизнеслогике эти классы взаимодействуют.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[9]: ддд с чего начать
От: Sinix  
Дата: 20.02.16 05:53
Оценка: +1 :)
Здравствуйте, LeonidV, Вы писали:

O>>>Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.

LV>Вот как раз это не потеряло своей актуальности. Что-то, конечно устарело или перодилось в oninon architecture или CQRS.

Ну дык оно не на любой язык / фреймворк хорошо ложится. Смысл натягивать DDD репо с сложной схемой на сервис на ноде?

Смысл переобзывать EF context репозиторием или даже аггрегатором (ага, бесконечный повод для срача), или пытаться сделать domain typed values на языке, который их не поддерживает?

В общем вся эта часть насквозь сфероконична и не имеет особой практической ценности. Повезло, и выбранный язык / фреймворк имеет похожие концепции? Ок, используем. Нет — не заморачиваемся и двигаемся дальше.

Из той же серии — нелюбовь к anemic. Ах, это процедурное программирование, там некуда прикрутить ООП (почти дословно один из диалогов) В последнее время я предпочитаю вместо объяснений просто сказать, что это не процедурное программирование, а тру-ФП-стайл. Как ни странно, получается быстрее
Re[9]: ддд с чего начать
От: Sinix  
Дата: 20.02.16 06:11
Оценка:
Здравствуйте, okon, Вы писали:

O>мне пока не повезло увидеть ТЗ такое чтоб вот сделал как в нем написано и все были довольны.

O>Да и какое ТЗ может быть в agile ? Только очень краткое.

Ну я ж говорю — DDD не построит за вас нормальный рабочий процесс. Утрируя, если принят стиль "сначала пишем код, а затем узнаём, что он должен был делать", то тут уже ничего не спасёт

Никакие красивые слова не отменяют ТЗ. Как вы ещё собираетесь обосновать заказчику, за что он вам банкет оплачивает?


O>>>Ему нужен программный продукт, в вот собственно продукт получается когда мы написали N cтрок кода.

S>>Нафига заказчику код? Бизнес всегда покупает не продукт, а решение своих проблем. Собственно про это ТЗ и пишется.
O>Ну да , а для решения проблемы нужен продукт, а продукт чтобы появился нужно написать код.

Ок, кривая аналогия: зубную щётку покупают, чтоб у вас была щётка или потому что зубы надо почистить?
Сам по себе, в отрыве от его прикладных функций, продукт не имеет никакой ценности (про фетишистов не будем). Продукт получается, не когда написали N строк, а когда у заказчика вместо двух отделов справляется один человек и приёмку подписывают со словами "спасибо конечно, но больше никогда так не делайте"


O>>>Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.

O>Пока сложно прикинуть, ибо надо понимать зачем эти вещи введены и что они значат, почему не хватает обычного деления на Data,Business
Просто забейте. Всё равно на практике получается компромисс из того что хочется и того, что легко пишется на выбранном языке/фреймворке. Смысл зацикливаться на вещах, если их внедрение замедляет разработку в n раз, да ещё и даёт -5 к морали команды?


S>>У вас есть часть, которая практически гарантированно не меняется — модель предметной области.

O>А зачем тут новые 3 слова ддд, чем это не вписывается в практику 90х — каждая сущность класс и в бизнеслогике эти классы взаимодействуют.
Ну блииин... Да не поменялось ничего принципиально ещё со времён мифического человекомесяца. Разведка-обдумывание-реализация-контроль и так до посинения, вопрос только в вкусе фломастеров отдельных нюансах.

Ну, если совсем грубо: В DDD предлагается шлёпать сущности не абы как, а отражая реалии предметной области (см в предыдущем посте пример с сотрудником), вот и всё.
Re[10]: ддд с чего начать
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.02.16 13:15
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Ну, если совсем грубо: В DDD предлагается шлёпать сущности не абы как, а отражая реалии предметной области (см в предыдущем посте пример с сотрудником), вот и всё.


А в не-DDD как предлагается делать?
Re[11]: ддд с чего начать
От: Sinix  
Дата: 20.02.16 13:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>Ну, если совсем грубо: В DDD предлагается шлёпать сущности не абы как, а отражая реалии предметной области (см в предыдущем посте пример с сотрудником), вот и всё.

G>А в не-DDD как предлагается делать?

Да то же самое по большому счёту. Ну, если не перебарщивать с акын-стайл методиками (aka что вижу, то и пишу).
Вся разница — в DDD расписаны базовые принципы, в остальных — всё на откуп аналитику/архитектору.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.