Он подчеркивает важность понимания бизнес-процессов и правил предметной области и их отражения в коде. Более эффективную модель процесса разработки сложных проектов предлагает Domain-Driven Design (DDD), или предметно-ориентированное проектирование. Это методология, которая применяется для получения высококачественной модели программного обеспечения, максимально точно отражающей поставленные бизнес-цели. DDD — подход к разработке, основанный на выделении логики в area (домены).
- DDD подчеркивает что код и бизнес должны говорить на одном языке.
- Я показал примерное расположение файлов и папок, которое я делаю в своих проектах, которое я считаю за DDD.
- Главный элемент здесь — это Entity (сущность), имеющая уникальный id. Она описывает индивидуально существующие элементы домена и определяется по id, а не по значению каких-то атрибутов.
- Подход DDD подразумевает, что каждому участнику проекта доступна полная и целостная информация о предметной области и бизнес-процессах.
- Это пространство показывает стратегические задачи, которые решаются для выполнения главных бизнес-целей.
Моделирование Доменов
Если у нас есть какой-то аккаунт, мы хотим видеть не просто, что на нем лежит a hundred рублей, а каким образом эти деньги накопились. Если у вас есть два Ивановых Алексея, то они будут двумя разными людьми, даже если у них совпадают поля. Worth Object — например, деньги — может содержать валюты и quantity. И если эти два поля совпадают, вы считаете, что это одинаковые вещи. Это всё порождает связанность (coupling) и одновременно слабую кохезию (cohesion), то есть мы не понимаем без полного прочтения кода, что и как взаимосвязано в этой системе. Так как кодовая база у больших legacy-проектов со временем становится огромной, то в итоге вообще никто не понимает этих связей.
Неспособность Достичь Общего Понимания Между Членами Команды
Стоит всегда помнить, что значение объекта никогда не изменяется на протяжении выполнения всего программного кода. DDD – area driven design или предметно-ориентированное программирование. DDD Ручное тестирование обязывает разработчика создавать абстракции, в которые входит бизнес логика. По сути это связующее звено между продуктом (бизнесом) и программным кодом.
Основные Принципы Ddd
К тому же, новые сотрудники гораздо проще проходят онбординг и вливаются в работу. Пространство решений — это конкретные ограниченные контексты, которые способствуют решению этих стратегических задач. То есть, это те IT-решения, которые помогают достичь бизнес-цели.
Сложное практически всегда состоит из простых частей, соединенных простыми связями. Благодаря применению Domain-Driven Design код веб-сервиса или мобильного приложения получается несложным и понятным. В итоге упрощается его чтение, а значит — поддержка и развитие сервиса в будущем. Чтобы сервис корректно работал и выполнял все свои функции, между модулями системы нужно настроить связи. Такое разрастание функционала грозит образованием «больших комков грязи» — huge balls of mud.
Мы использовали подход Domain-Driven Design для создания информационной системы «Абитуриент», которая автоматизировала работу приемной комиссии Сибирского федерального университета. В процессе проектирования возникали все новые и новые потребности, архитектура сервиса разрасталась. Более краткое изложение https://deveducation.com/ принципов Domain-Driven Design можно найти у Вона Вернона в издании «Предметно-ориентированное проектирование.
Другими словами, программист должен до некоторого уровня стать экспертом в предметной области. Есть соблазн запихать все в один большой агрегат, потому что он всегда будет консистентным. Вон Вернон настаивает, что агрегат должен сохраняться транзакционно. Для планировщика, который работает внутри смартфона, это возможно.
В итоге, он может стать мощным союзником в создании гибких и эффективных программных решений. Хотя по концепции предметно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике используются сильные стороны объектно-ориентированного программирования. Это использование наследования, инкапсуляции, представления в виде методов и классов. Нужно помнить, что предметно-ориентированный подход может быть применен не только к ООП языкам, таким как Java, C# или C++, но так же и к функциональным — F#, Erlang. Особенно удобны языки, поддерживающие создание и использование собственных предметно-ориентированных языков, такие как Scala (см. также ЯОП).
Эффективная реализация этих тактических шаблонов требует глубокого понимания предметной области и принцип ddd базовой бизнес-логики. С помощью этих шаблонов разработчики могут лучше выразить сложность предметной области, что приводит к созданию более удобной в обслуживании и выразительной базы кода. Так почему код должен быть на языке отличном от языка бизнеса?
И справа выделен красным один из них — это атрибут Handle со своими полями Road, Metropolis и т.д. Главный элемент здесь — это Entity (сущность), имеющая уникальный id. Она описывает индивидуально существующие элементы домена и определяется по id, а не по значению каких-то атрибутов. Но после внедрения DDD мы получаем модульный проект, модули которого не зависимы друг от друга, внедрение доработок упрощено, понимание на 80-ом уровне (все говорят на одном понятном языке). Далее начинаем отсекать все остальное от ядра всей системы в Supporting subdomain, чтобы это было независимо, не взаимосвязано и упрощало внесение доработок в ту или иную часть. Хотя в интернете можно найти много противников данного подхода, так же как и противников Spring Framework, который больше предпочитают Google Guice. Но мы не будем говорить сейчас об этом, вы можете сами более детально продолжать изучать эти концепции и прийти к собственному выводу.
Специалист крайне востребован, если одинаково хорошо разбирается и в технической стороне разработки, и, например, в тонкостях бухучета, банковского дела, логистики, узкой отрасли промышленности или медицины. Разработка проекта со сложной бизнес-логикой требует от команды много усилий, времени, глубокого изучения предметной области и умения решать нетривиальные технические задачи. Такой подход ускоряет процесс проектирования ПО в незнакомой для разработчика области. В проектах, в которых сложность и запутанность бизнес-логики достаточно велика, DDD должен снизить эту сложность. DDD используется для упрощения сложных приложений, разбивая их на более мелкие и управляемые части, которые тесно связаны с реальными бизнес-процессами.
