Понимание дизайна, управляемого доменом (DDD)
17 февраля 2023 г.Это было более чем Прошло 50 лет с тех пор, как была изобретена архитектура программного обеспечения как концепция, но до сих пор задержки проектов и неэффективное управление по-прежнему преследуют отрасль. Некоторые вещи неизбежны, потому что экосистема программного обеспечения — это постоянно движущаяся цель, поверьте мне, это реальность. Это то, с чем сталкивался каждый инженер-программист. В этой статье я расскажу о другом подходе к навигации по программным архитектурам.
Domain Driven Design (DDD) – это архитектурный шаблон, который помогает нам понять программное обеспечение, которое мы создаем, путем моделирования классов на основе бизнес-требований. Этот подход заключается в том, чтобы отложить в сторону технологию, которую вы должны использовать, и сосредоточиться на проблемной области. Этот шаблон проектирования использует инструменты стратегического и тактического моделирования для решения бизнес-задач.
Для начала все, что вам нужно, это ручка и бумага.
DDD — это не технология. Вместо этого все дело в понимании проблемы, которую вы должны решить в контексте бизнеса.
Чтобы понять, как работает бизнес, вам нужно принять участие в некоторых дискуссиях с вашей командой. Это дает вам глубокое понимание бизнес-целей и позволяет эффективно выполнять обнаружение программного обеспечения. Прежде чем узнать, что такое DDD, давайте обсудим многоуровневую архитектуру.
Многоуровневая архитектура
В то время было только два слоя: представление и данные. Итак, где бизнес-логика? Традиционно бизнес-логика кодировалась на уровне представления (также известном как пользовательский интерфейс). В идеале это ускоряет разработку — если вы разработчик-одиночка. В конце концов появилась многоуровневая архитектура, в которой обязанности по коду были разделены на четыре уровня.
* Слой представления. Для этого слоя существует только одно задание, которое заключается в отображении данных для пользователя. * Прикладной уровень — этот слой тонкий. Он не содержит никакой бизнес-логики. Состояние задачи находится в процессе внутри этого слоя. * Доменный уровень — это сердце программного обеспечения. Он содержит всю бизнес-логику. Слой предметной области — это постоянное невежество. * Уровень инфраструктуры. Вы можете думать об этом как о вспомогательном уровне. Это способствует коммуникации между другими слоями.
Три столпа доменно-ориентированного дизайна
Чтобы понять DDD, нам нужно знать, из чего он состоит.
Вездесущий язык
При проектировании, ориентированном на предметную область, очень важно, чтобы инженеры-программисты и специалисты в предметной области работали вместе. Нет этой команды против той команды, это все одна большая команда.
Создание универсального языка принесет пользу всем людям, работающим над программным обеспечением, поскольку и разработчики, и клиенты говорят на одном языке. Вездесущий язык — это язык бизнеса, поэтому инженер, работающий с системой, должен понимать бизнес.
А пока будем считать, что ограниченный контекст — это граница вокруг системы.
клиент внутри ограниченного контекста — это вездесущий язык. Поэтому термин «клиент» имеет разное значение в каждой границе.
Стратегический дизайн
Основная цель этого проекта – определить ограниченный контекст, вездесущий язык и контекстную карту внутри системы.
* Ограниченный контекст. Вы можете думать об этом как о границе вашего вездесущего языка. Например, клиенты в контексте доставки и финансов имеют разные значения. В финансовом контексте клиент является объектом или основным объектом этого контекста, в то время как в контексте доставки клиент является только объектом стоимости заказа. Если обсуждение не соответствует сценарию клиента, значит, ваша команда вырвана из контекста.
* Контекстные карты. Когда вы закончите создание двух или более ограниченных контекстов, между этими границами появится связь. Сопоставление контекста — это способ моделирования и соединения границ путем визуализации отношений между этими контекстами.
Тактический дизайн
Этот дизайн используется, когда вы создаете свою модель предметной области внутри вашего ограниченного контекста. Строительные блоки — это сущности, объекты значений, агрегаты, службы и репозитории.
* Сущности - это класс, который имеет индивидуальность и остается такой же продуманной вашей системой. * Объекты-значения — это тоже класс, но, в отличие от сущностей, у него нет идентификатора. Объекты-значения используются сущностями для представления таких атрибутов, как возраст, адрес и т. д. Атрибут проверяется внутри класса объекта значения. * Службы — у каждого слоя есть служба. Например, одна из служб внутри приложения называется службой приложения. Назначение службы приложений — управлять потоком вариантов использования в системе. * Репозитории. Если вы разработчик программного обеспечения, вы уже слышали об этом и, вероятно, имеете представление о том, что это такое. Репозитории — это абстракция вашей базы данных (код SQL). Вы назвали абстракцию на основе языка, используемого в бизнесе, например getAllSingleStatusUsers().
Заключение
В разработке программного обеспечения не существует единого решения для каждой проблемы. Если у вас небольшое приложение или требования включают только основные функции CRUD, я не думаю, что вам нужен DDD. Все зависит от приложения, которое вы создаете. Вы можете попробовать дизайн архитектуры DDD, если ваше приложение растет и имеет много функций.
Надеюсь, вы наконец поняли основную концепцию DDD. В моей следующей статье сущности и объекты-значения с некоторыми примерами кодов.
Какой архитектурный шаблон вы используете в настоящее время? Сталкиваетесь ли вы с проблемами при масштабировании? Дайте мне знать в комментариях и не забудьте поделиться этой статьей.
Спасибо за прочтение. (-:
Также опубликовано здесь
Оригинал