Методология проектирования: вариант использования, управляемый по сравнению с управляемым доменом
Удалить кавычки вокруг регулярных выражений. В JS регулярные выражения вводятся при разборе /, они не являются строками.
var $input = $("input");
$input.attr("name", $input.prop("name").replace(/\[.*?\]/g, "[2]"));
$input.attr("id", $input.prop("id").replace(/\_.d?\__/g, "_2__"));
alert($input.attr("name"));
alert($input.attr("id"));<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<input data-val="true" data-val-number="The field TotalValue must be a number." id="Notice_NoticeDetails_0__TotalValue" name="Notice.NoticeDetails[0].TotalValue" type="text" value="">6 ответов
Use Cases фокусируются на Пользователях, действиях и процессах. Это отлично с точки зрения бизнеса, поскольку каждый может увидеть абстрактное представление того, что будет предоставлять система.
DDD фокусируется на создании программного обеспечения, которое решает проблемы. Вопросы 'Кто может это решить?' и 'Какому процессу они будут следовать?' появляются после.
DDD действительно добирается до основных проблем на ранних стадиях процесса проектирования и помогает вам структурировать ваше решение (т.е. определить сущности, объекты ценности, репозитории, сервисы домена/приложения/инфраструктуры, ограниченные контексты, спецификации и т.д.).
Use Cases вообще не учитывают этого, или как управлять разработкой (Антикоррупционные слои, отдельные пути и т.д.)
По моему опыту, DDD предлагает большую гибкость (меняющиеся требования?), и обеспечивает основу для ваших Use Cases. После того как у вас есть модель домена, Use Cases могут быть реализованы с помощью контроллеров/движков рабочих процессов/инструментов, которые связаны с вашей моделью домена. Довольно часто я выявлял пробелы в бизнес-требованиях, просто построив модели доменов.
И, посетив несколько лет назад доклад Ивара Якобсена, я бы также сказал, что DDD лучше подходит для Agile.
Подход, основанный на сценарии использования , работает хорошо, если у вас есть только один клиент для продукта , и клиент уже рассказал вам обо всех проблемах, которые необходимо решить с помощью продукта. Это возможно в сервис-ориентированных компаниях в целом. Это становится трудно управлять, когда у вас есть несколько клиентов для одного и того же продукта. Обычно это происходит в компаниях, разрабатывающих продукты. В таких случаях (Product Driven Companies) DDD пригодится. Вы разрабатываете продукт, используя DDD (вы называете его базой). Затем проверьте, применимы ли все варианты использования для нового клиента, если нет, то сформируйте слой поверх базы для изменений, специфичных для клиента.
Домен-управляемый дизайн, по сути, пытается действовать так, как будто вы знали все возможные варианты использования заранее. По определению, «проблемный» домен - это набор конкретных проблем, которые считаются членами этого домена.
На мой взгляд, проектирование, ориентированное на домен (DDD), является более "всеобъемлющим"; в то время как Use Cases - это просто инструмент, который фокусируется на конкретном представлении: как что-то реагирует на стимул и используется для фиксации или документирования поведенческих требований.
На мой взгляд, термин "домен" является тяжелым - он подразумевает более широкий взгляд на все концепции, относящиеся к конкретной проблемной области.
При описании того, как части домена взаимодействуют - в частности, как они реагируют на стимул, можно использовать Use Cases.
Что касается подхода: Use Cases - это "дополнительное" представление в 4+1 Architectural View Model, но сами по себе они не являются подходом к проектированию.
Другое различие заключается в том, что DDD часто очень тесно связан с объектно-ориентированной моделью или системой; таким образом DDD фиксирует/представляет (помимо прочего) структуру системы - то, чего не делают Use Cases.
Это моя личная интерпретация, основанная на опыте.
Проектирование на основе сценариев использования использует сценарии использования в качестве инструмента для выявления сущности, интерфейса, сообщения о взаимодействии и рабочего процесса, как выполняется определенная бизнес-операция. Это часто используется на стадии анализа или проектирования для сбора или понимания требований и создания некоторых начальных проектов. DDD, с другой стороны, больше ориентирован на реализацию с сильным фокусом на сущности и контексте домена. Он фокусируется на более подробных деталях, чем сценарий использования, в плане определения модели (таких как классы, интерфейсы) и определения ее границ, агрегаций, операций и логики, специфичной для домена. Как правило, он следует некоторой стандартной практике того, как подходить к ним в реализации.
DDD больше подходит, когда вы имеете дело с проектом, ориентированным на конкретную область, такую как бухгалтерский учет, машиностроение, где вы можете предвидеть, что некоторые или большинство моделей в бизнесе могут иметь сложную взаимосвязь и воплощенную логику. Выбор между проектированием на основе сценариев использования и DDD также зависит от наличия специалистов в данной области. Если у вас есть заинтересованные стороны с бизнес-потребностями (только некоторый доступ к экспертам домена), то проектирование на основе примеров использования более подходящее, чем DDD. Если у вас нет экспертов домена, принимающих непосредственное участие в разработке проекта, то DDD - это высокий риск.
Лично я думаю, что они оба могут дополнять друг друга в некоторых проектах, где вы можете начать с проектирования на основе сценариев использования и подойти к детальному проектированию и реализации, используя подход DDD
.Я не эксперт в этом, и эти термины могут быть нечеткими и означать разные вещи для разных людей. Но...
я бы сказал, что Domain Design - это когда есть существующая система (бумажная, ручная, какая угодно), а программное обеспечение моделирует фактические сущности в системе. Так, в библиотечной системе вы смотрите на библиотеку и видите, что там есть книги, полки, шкафы и комнаты. И на основе этого вы моделируете реальную область в программном обеспечении.
С Use case вы начинаете с "что мы пытаемся сделать" Может оказаться, что вам не нужны различные комнаты в вашей модели, потому что они не нужны в сценариях использования. Это делает вашу систему более простой (и менее подверженной ошибкам), но если вы не моделируете "реальный мир", вы теряете некоторую гибкость.