Методология проектирования: использование управляемых приложений с использованием домена

Ответ 1

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

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

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

Использовать Случаи не подходят для этого вообще или как управлять вашей разработкой (Anti-Corruption Layers, Раздельные способы и т.д.)

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

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

Ответ 2

Для меня Domain-Driven Design (DDD) более "все emcompassing"; где как "Случаи использования" - это просто инструмент, который фокусируется на конкретном представлении: как что-то реагирует на стимулы и используется для захвата или документирования поведенческих требований.

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

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

Что касается подхода: "Использовать случаи" - это "дополнительное" представление в 4 + 1 Архитектурная модель просмотра, но они не" t подход к проектированию самостоятельно.

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

Ответ 3

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

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

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

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

Ответ 4

Использовать подход, основанный на использовании case, работает отлично, если у вас есть только один клиент для продукта, и клиент уже рассказал вам обо всех проблемах, которые должны быть решены продуктом. Это возможно в сервис-ориентированных компаниях в целом. Сложно управлять, когда у вас несколько клиентов для одного продукта. Это обычно происходит в развивающихся компаниях. В таких случаях подходит (Product Driven Companies) DDD. Вы разрабатываете продукт с использованием DDD (вы называете его базовым). Затем проверьте, применимы ли все варианты использования нового клиента, если они затем не образуют слой над базой для конкретных изменений клиента.

Ответ 5

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

Ответ 6

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

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

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