Методология проектирования: использование прецедента или домена - PullRequest
23 голосов
/ 04 июля 2010

Просто для обсуждения, мне кажется, что две разные термины на самом деле говорят одно и то же.Есть ли ощутимые различия между этими двумя подходами к проектированию?

Ответы [ 6 ]

23 голосов
/ 09 июля 2010

Варианты использования Фокус на Пользователи, Действия и Процессы .Это замечательно с точки зрения бизнеса, потому что каждый может видеть абстрактное представление о том, что будет предоставлять система.

DDD фокусируется на создании программного обеспечения, которое решает проблемы.' Кто может решить эту проблему? ' и ' Какой процесс они будут выполнять? ' последуют позже.

DDD действительно добирается доосновные проблемы, возникшие ранее в процессе проектирования, и помогает вам структурировать ваше решение (т. е. идентифицировать сущности, объекты-значения, хранилища, службы домена / приложения / инфраструктуры, ограниченный контекст, спецификации и т. д. ).

Варианты использования не учитывают это вообще, или как управлять вашей разработкой ( Антикоррупционные слои, отдельные способы и т. Д. )

По моему опыту, DDD предлагает больше гибкости (изменяет ли кто-нибудь требования?) И обеспечивает основу для ваших вариантов использования.Как только вы установили модель домена , варианты использования могут быть реализованы с использованием контроллеров / модулей рабочих процессов / пользовательских интерфейсов , которые связаны с вашей моделью домена.Довольно часто я выявлял пробелы в бизнес-требованиях, просто создавая доменные модели.

И, побывав на выступлении Ивара Якобсена несколько лет назад, я бы также сказал, что DDD лучше подходит для Agile.

8 голосов
/ 04 июля 2010

Для меня доменно-управляемый дизайн (DDD) является более «всеобъемлющим»; где как варианты использования - это просто инструмент, который фокусируется на конкретном представлении: как что-то реагирует на стимулы и используется для сбора или документирования поведенческих требований.

Для меня термин «домен» является загруженным - он дает более широкое представление обо всех концепциях, относящихся к конкретной проблемной области.

Когда вы описываете, как части домена взаимодействуют, в частности, как они реагируют на стимул, вы можете использовать варианты использования.

Что касается подхода: варианты использования являются «дополнительным» представлением в 4 + 1 модели архитектурного представления , но сами по себе они не являются конструктивным подходом.

Другое отличие состоит в том, что DDD часто очень тесно связан с объектно-ориентированной моделью или системой; таким образом, DDD фиксирует / представляет (среди прочего) структуру системы - что-то, чего не используют сценарии использования.

3 голосов
/ 17 июля 2010

Подход, основанный на сценарии использования , работает нормально, если у вас есть только один клиент для продукта , и клиент уже сообщил вам обо всех проблемах, которые необходимо решить с помощью продукта.Это возможно в сервис-ориентированных компаниях в целом.Это становится трудно управлять, когда у вас есть несколько клиентов для одного и того же продукта.Обычно это происходит в компаниях, разрабатывающих продукты.В таких случаях (Компании, управляемые продуктами) DDD пригодится.Вы разрабатываете продукт с использованием DDD (вы называете его базой). Затем проверьте, применимы ли все варианты использования для нового клиента, если нет, то сформируйте слой поверх базы для изменений, специфичных для клиента.

2 голосов
/ 09 июля 2010

Это моя личная интерпретация, основанная на опыте.

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

DDD больше подходит, когда вы имеете дело с проектом, который нацелен на конкретную область, такую ​​как бухгалтерский учет, инжиниринг, где вы можете предвидеть, что некоторые или большинство моделей в бизнесе могут иметь сложную взаимосвязь и воплощенную логику.Выбор между дизайном, основанным на сценариях использования или DDD, также зависит от наличия экспертов в предметной области.Если у вас есть заинтересованные стороны с бизнес-потребностями (только некоторый доступ к экспертам в области), то дизайн, основанный на сценариях использования, является более подходящим по сравнению с DDD. Существует высокий риск принятия DDD, если у вас нет экспертов по предметной области, непосредственно участвующих в разработкепроект.

Лично я думаю, что они могут дополнять друг друга в некоторых проектах, где вы можете начать с разработки на основе сценариев использования и приблизиться к детальному проектированию и реализации с использованием подхода DDD

1 голос
/ 23 июля 2010

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

Я бы сказал, что Доменный дизайн был там, где существовала система (бумажная, ручная и т. Д.), И программное обеспечение моделирует реальные объекты в системе. Итак, в библиотечной системе вы смотрите на библиотеку и видите, что есть книги, полки, шкафы и комнаты. И на основании этого вы моделируете реальный домен в программном обеспечении.

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

1 голос
/ 12 июля 2010

Домен-управляемый дизайн, по сути, пытается действовать так, как будто вы знали все возможные варианты использования заранее. По определению «проблемный» домен - это набор конкретных проблем, которые считаются членами этого домена.

...