По мере развития информационных технологий и разработки нового программного обеспечения компании ищут все больше способов относительно быстрого создания безопасных приложений и систем, которые охватывают все условия и при этом легко тестируются и разрабатываются. На основе проб и ошибок был создан подход, который многими организациями рассматривается как идеальный способ создания программного обеспечения.
Речь идет о Domain Driven Design. В чем именно заключается подобный подход к разработке программ в компании?
Domain Driven Design (сокращенное название DDD) — что это за подход?
В самом начале стоит определить, что именно представляет собой подход DDD. Это способ создания приложений и систем, которые должны в основном отражать потребности бизнеса — бизнес-предположения, которые в то же время становятся необходимыми условиями, включенными в программное обеспечение.
Какие исходные данные лежат в основе метода DDD? Прежде всего, проектирование любого ПО должно основываться на равноправном сотрудничестве между программистами и людьми, непосредственно связанными с бизнесом, которые в то же время являются целевым потребителем решения. Вторым условием создания систем методом DDD является проектирование логики проекта в виде доменов.
Что такое домен? В двух словах — это конкретная область бизнеса, которую необходимо реализовать. Область, которая должна быть улучшена с помощью вновь созданного или разработанного ПО. В зависимости от важности и сути конкретной концепции и функциональности, мы можем разделить домены на:
- Основные домены, которые являются наиболее важной частью системы и отвечают за наиболее важные функциональные возможности.
- Домены поддержки, которые являются расширением основного домена — без него домены поддержки ничего не стоят.
- Общие домены, которые являются важными, но дополнительными функциями.
Из чего состоит DDD?
Процесс создания нового программного обеспечения на основании принципов Domain Driven Design несколько отличается от традиционного подхода к разработке программ, который включает в себя ряд технических вопросов, связанных с обработкой механики, вводом и выводом данных, связью с сервером, базой данных и интеграцией с другими инструментами, используемыми организацией.
DDD-программирование состоит в основном из моделей доменов (корневых, вспомогательных и общих доменов), которые содержат очень базовую реализацию параметров бизнеса, которые должны быть включены в программное обеспечение. Очень важно, чтобы программист, ответственный за разработку кода, досконально понимал цель создания нового программного обеспечения и осознавал ценность, которую несет в себе домен. DDD не может обойтись без определения языка, который позволит экспертам домена и программистам легко понимать этот язык. За такой подход этот язык получил название Ubiquitous language.
Какие трудности могут возникнуть при использовании Domain Driven Design подхода?
В чем состоит самая большая проблема при использовании DDD-метода? Прежде всего, это коммуникация между бизнесом и технической стороной. Как правило, в подходе DDD всегда должно быть место для доменного эксперта, который обладает глубокими знаниями о подходе и будет самостоятельно выступать в качестве «компилятора» в коммуникации бизнеса и IТ.
Из-за относительно небольшого процента проектов, созданных с использованием метода DDD, очень трудно найти человека, который мог бы взять на себя такую роль с полной отдачей. Отсутствие должного опыта у программистов в создании с помощью методологии DDD также может вызвать дополнительные трудности.
Преимущества и недостатки подхода DDD
Давайте начнем с преимуществ использования Domain Driven Design-подхода при создании нового программного обеспечения. Прежде всего, это отличное решение в случае сложных проектов, где количество функциональных возможностей, целей их реализации и различных уровней настолько велико, что его трудно концептуально охватить при традиционном проектировании приложения. DDD-подход отвечает реальным потребностям бизнеса — здесь нет места полумерам — если домен правильно интерпретирован программистом, он будет реализован в полном соответствии с потребностями конечного пользователя. Стоит также отметить относительно низкую стоимость разработки приложения, которое с самого начала было создано в соответствии с подходом DDD.
А какие недостатки говорят против использования этой методики? Основным недостатком является небольшая практика использования этого способа разработки нового программного обеспечения. Из-за этого начало использования новой стратегии, с точки зрения команды проекта, несет риск полного непонимания концепции и, как следствие, провала.
Первоначальная производственная стоимость проектирования и создания приложения с использованием методологии DDD выше, что, безусловно, влияет на небольшой процент проектов, реализуемых таким образом.
Как использовать DDD в собственном проекте?
Для того чтобы DDD можно было применить на практике в нашем проекте, мы должны фактически начать с нуля. Невозможно частично принять Domain Driven Design-концепцию, где остальная часть модели будет спроектирована традиционным способом. В этом случае удовлетворенность конечным продуктом будет низкой как со стороны IT-команды, так и со стороны конечного пользователя.
