Здравствуйте, 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%