Методология проектирования: использование прецедента или домена
Просто для обсуждения, мне кажется, что две разные термины на самом деле говорят одно и то же. Есть ли ощутимые различия между этими двумя подходами к дизайну?
6 ответов
Варианты использования фокусируются на пользователях, действиях и процессах. Это замечательно с точки зрения бизнеса, потому что каждый может видеть абстрактное представление о том, что будет предоставлять система.
DDD фокусируется на создании программного обеспечения, которое решает проблемы. " Кто может решить это? и " Какой процесс они будут следовать? прийти позже.
DDD действительно доходит до основных проблем на ранних этапах процесса проектирования и помогает вам структурировать ваше решение (т. Е. Идентифицировать сущности, объекты-значения, репозитории, службы домена / приложения / инфраструктуры, ограниченный контекст, спецификации и т. Д.).
Варианты использования не учитывают это вообще, или как управлять вашей разработкой (антикоррупционные уровни, отдельные способы и т. Д.)
По моему опыту, DDD предлагает больше гибкости (кто-нибудь меняет требования?) И обеспечивает основу для ваших вариантов использования. Когда у вас есть модель домена, варианты использования могут быть реализованы с помощью контроллеров / модулей рабочих процессов / пользовательских интерфейсов, которые связаны с вашей моделью домена. Довольно часто я выявлял пробелы в бизнес-требованиях, просто создавая доменные модели.
И, побывав на выступлении Ивара Якобсена несколько лет назад, я бы также сказал, что DDD лучше подходит Agile.
Для меня Domain-Driven Design (DDD) является более "всеобъемлющим"; где как варианты использования - это просто инструмент, который фокусируется на конкретном представлении: как что-то реагирует на стимулы и используется для сбора или документирования поведенческих требований.
Для меня термин "домен" является нагруженным - он дает более широкое представление обо всех концепциях, относящихся к конкретной проблемной области.
При описании взаимодействия частей домена - в частности, как они реагируют на стимулы, вы можете использовать варианты использования.
Что касается подхода: варианты использования являются "дополнительным" представлением в модели архитектурного представления 4+1, но сами по себе они не являются подходом к проектированию.
Другое отличие состоит в том, что DDD часто очень тесно связан с объектно-ориентированной моделью или системой; таким образом, DDD фиксирует / представляет (среди прочего) структуру системы - что-то, чего не делают Сценарии использования.
Это моя личная интерпретация, основанная на опыте.
Конструкция, основанная на сценариях использования, использует сценарий использования в качестве инструмента для обнаружения сущности, интерфейса, сообщения взаимодействия и рабочего процесса о том, как выполняется определенная бизнес-операция. Это часто используется на этапе анализа или проектирования, чтобы собрать или понять требования и установить некоторые начальные проекты. DDD, с другой стороны, больше ориентирован на реализацию с сильным акцентом на сущности и контексте домена. Он фокусируется более детально, чем вариант использования, в терминах определения модели (такой как классы, интерфейсы) и определения ее границы, агрегатов, операций и логики, специфичной для предметной области. Как правило, он следует некоторой стандартной практике того, как подходить к ним при реализации.
DDD больше подходит, когда вы имеете дело с проектом, который нацелен на конкретную область, такую как бухгалтерский учет, инжиниринг, где вы можете предвидеть, что некоторые или большинство моделей в бизнесе могут иметь сложную взаимосвязь и воплощенную логику. Выбор между дизайном, основанным на сценариях использования или DDD, также зависит от наличия экспертов в предметной области. Если у вас есть заинтересованные стороны с бизнес-потребностями (только некоторый доступ к экспертам в области), то дизайн, основанный на сценариях использования, является более подходящим по сравнению с DDD. Существует высокий риск принятия DDD, если у вас нет экспертов по предметной области, непосредственно участвующих в разработке проект.
Лично я думаю, что они могут дополнять друг друга в некоторых проектах, где вы можете начать с разработки на основе сценариев использования и подходить к детальному проектированию и реализации с использованием подхода DDD.
Домен-управляемый дизайн, по сути, пытается действовать так, как будто вы заранее знаете все возможные варианты использования. По определению "проблемный" домен - это набор конкретных проблем, которые считаются членами этого домена.
Подход,основанный на сценариях использования, работает хорошо, если у вас есть только один клиент для продукта, и клиент уже рассказал вам обо всех проблемах, которые необходимо решить с помощью продукта. Это возможно в сервис-ориентированных компаниях в целом. Это становится трудно управлять, когда у вас есть несколько клиентов для одного и того же продукта. Это обычно происходит в компаниях, разрабатывающих продукты. В таких случаях (компании, управляемые продуктами) DDD пригодится. Вы разрабатываете продукт, используя DDD (вы называете его базой). Затем проверьте, применимы ли все варианты использования для нового клиента, если нет, то сформируйте слой поверх базы для изменений, специфичных для клиента.
Я не эксперт в этом, и эти термины могут быть нечеткими и означать разные вещи для разных людей. Но..
Я бы сказал, что Доменный Дизайн был там, где существовала система (бумажная, ручная и т. Д.), И программное обеспечение моделирует реальные объекты в системе. Итак, в библиотечной системе вы смотрите на библиотеку и видите, что есть книги, полки, шкафы и комнаты. И на основании этого вы моделируете реальный домен в программном обеспечении.
С помощью варианта использования вы начинаете с того, "что мы пытаемся сделать". Возможно, вам не нужны разные комнаты в вашей модели, потому что они не нужны в вариантах использования. Это делает вашу систему проще (и менее подверженной ошибкам), но если вы не моделируете "реальный мир", вы теряете некоторую гибкость.