Программисты давно написали специальные инструменты, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). Прежде всего, проектирование любого ПО должно основываться на равноправном сотрудничестве между программистами и людьми, непосредственно ddd что это связанными с бизнесом, которые в то же время являются целевым потребителем решения. Вторым условием создания систем методом DDD является проектирование логики проекта в виде доменов. В самом начале стоит определить, что именно представляет собой подход DDD.
Например, разработчикам при использовании этого подхода нужно внимательнее подходить к созданию и изменению сущностей и связей, к переименованию. Чтобы сервис корректно работал и выполнял все свои функции, между модулями системы нужно настроить связи. DDD также включает в себя ряд паттернов и подходов, таких как агрегаты, репозитории, сервисы, фабрики и другие, которые помогают структурировать приложение и устранить избыточность кода. Если вы знаете, что ваше приложение будет расти и, вероятно, часто изменяться, то DDD определенно
поможет вам в контроле сложности и реализации рефакторинга вашей модели с течением времени. Если в вашем приложении реализует менее 30 сценариев использования (Use Cases), может вам проще использовать фреймворки Symfony или Laravel, для управления всей бизнес логикой.
DDD на практике. Проектирование списка желаний
Типы представляют из себя небольшие контрольные точки, благодаря которым, мы получаем множество мини-тестов по всему нашему приложению. Причем затраты на создание типов минимальны и актуализировать их не требуется, так как они являются частью кодовой базы. Сложное практически всегда состоит из простых частей, соединенных простыми связями. Благодаря применению Domain-Driven Design код веб-сервиса или мобильного приложения получается несложным и понятным. В итоге упрощается его чтение, а значит — поддержка и развитие сервиса в будущем. Также, если команда ранее не работала по Domain-Driven Design, то программистам придется изучать новые для себя инструменты, адаптироваться к более плотному сотрудничеству с клиентом.
Поскольку желания требуют регулярных вложений, неплохо было бы определить и базовую ставку, ниже которой сумма вклада быть не может. К тому же мы должны иметь возможность отслеживать вклады в любое из желаний, чтобы при необходимости их изымать. По мере накопления достаточного количества средств желание становится исполненным. Если же есть избыток денежных средств, то его можно перераспределить на другие свои желания (об этом в одной из следующих статей).
Domain driven design
Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.
Но DDD почти невозможен без чистой архитектуры проекта, так как при добавлении новой функциональности или изменении старой нужно стараться сохранять гибкость и прозрачность кодовой базы. Про порты, адаптеры и луковую архитектуру можно прочитать в отличной статье. Если записывать названия тестов в виде предложений и при записи имен методов использовать лексику бизнес-домена, созданная документация становится понятна заказчикам, аналитикам и тестировщикам. Из минусов только возрастающая сложность у языков с динамической типизацией. К примеру, для JavaScript этот подход тяжелее применить, чем для TypeScript.
.ddd Расширение файла
С помощью Domain-Driven Design мы структурировали сервис для СФУ. Выделили главный домен — прием документов от абитуриентов из разных городов. Такое разрастание функционала грозит образованием «больших комков грязи» — big balls of mud.
- Чтобы это учесть, я хочу предложить некоторый алгоритм работы над задачей с точки зрения предметно ориентированного проектирования.
- Вклад — это единовременно отложенная сумма денег на конкретное желание.
- Первоначальная производственная стоимость проектирования и создания приложения с использованием методологии DDD выше, что, безусловно, влияет на небольшой процент проектов, реализуемых таким образом.
- А еще они возможно более емко и лаконично описывают уже имеющееся понятие или процесс.
- Возможно, нам несколько повезло, потому что наша инфраструктура, благодаря коллегам, которые были до нас, уже была достаточно независимо от бизнес-кода.
Третий вариант — когда код настолько тесно связан с инфраструктурой, что просто не получается скрыть технический аспект — встречается также довольно часто. Тогда как внутри доменной модели мы хотим вообще не думать об инфраструктуре. И вообще желательно, чтобы пользователь, читая код доменной модели, не до конца понимал, что же происходит на инфраструктурном уровне. В отличие от серьезной большой библиотеки с бизнес-логикой, это не принесет вам головной боли.
Объект-значение[править править код]
Все участники общаются на нём, всё обсуждение происходит в терминах единого языка, и все артефакты максимально должны излагаться в терминах единого языка, то есть, начиная от ТЗ, и, заканчивая кодом. Если какое-то понятие предметной области является уникальным и отличным от всех других объектов в системе, то для его моделирования используется сущность. Такие объекты-сущности могут сильно отличаться своей формой за весь цикл существования, тем не менее их всегда можно однозначно идентифицировать и найти по запросу.
Для решения проблемы могут использоваться модели (model), которые описывают отдельные аспекты предметной области. Человек открывает главную страницу, ему нужно заказать перевозку — он нажимает на кнопку «отправить груз». В различных областях и профессиях могут быть и другие значения для аббревиатуры Ddd. В контексте разработки программного обеспечения основные значения связаны с Domain-Driven Design и жизненным циклом разработки.
Общий код
Вдобавок ко всему, вам придется приложить усилия, чтобы избежать технических моментов реализации на начальном этапе, а сосредоточиться в первую очередь о поведении объектов и создании единого языка (Ubiquitous Language). Это в свою очередь потребует открытого, здорового и
непрерывного диалога, чтобы успешно перенести их терминологию в модель программного обеспечения. Очень важно, чтобы программист, ответственный за разработку кода, досконально понимал цель создания нового программного обеспечения и осознавал ценность, которую несет в себе домен. DDD не может обойтись без определения языка, который позволит экспертам домена и программистам легко понимать этот язык.
Таким образом, объединяются пространство задач и пространство решений, выделяются модели предметной области в четко определенные области в зависимости от поставленных целей. Если система не разрабатывается с нуля, она часто представляет собой большой комок грязи, где подобласти пересекаются с ограниченными контекстами. Очень важно понимать, что в рамках предметной области смысл определенного термина или фразы может сильно отличаться. Существует некая граница, в пределах которой понятия единого языка имеют вполне конкретное контекстное значение – ограниченный контекст (Bounded context). Это второе по значимости свойство DDD после единого языка. Оба эти понятия взаимосвязаны и не могут существовать друг без друга.
