Практика
В DDD (Domain-Driven Design) существует множество нерешенных проблем, которые, возможно, были частично обсуждены на семинарах. Однако идеальных решений для любой задачи не существует — это всегда лишь аппроксимации. Существует множество методологий: сегодня популярны ООП (объектно-ориентированное программирование), AOP (аспектно-ориентированное программирование), DDD, TDD (тесто-ориентированная разработка), а завтра появятся еще новые подходы, которые будут активно обсуждаться.
Но, к сожалению, новые методологии разрабатываются очень долго, и многие из них все еще основываются на концепциях 90-х годов. Они часто не решают проблемы на 100%, потому что каждое решение порождает новые вызовы. Поэтому нельзя полагаться исключительно на одну методологию — необходимо брать из каждой только лучшие аспекты, применяя их для решения конкретных задач.
Такой подход, представляющий собой симбиоз различных методологий, эклектику лучших практик, позволяет наиболее эффективно справляться с возникающими проблемами в разработке.
Однако, на мой взгляд, DDD (Domain-Driven Design) привлекает три типа людей.
Первый тип — это программисты без образования в сфере ИТ или вооще без высшего образования. Такие специалисты часто ищут простые решения для сложных проблем и следуют за модными тенденциями в разработке, не понимая полностью сути методов и концепций. Им может казаться, что DDD — это нечто обязательное для использования, просто потому что это популярно и обсуждается на конференциях, в статьях или среди коллег. В результате они без глубокого анализа применяют DDD в тех областях, где эта методология не всегда оправдана или эффективна, что приводит к ненужным усложнениям проекта.
Второй тип — это программисты, которые никогда не работали над личными проектами, (который приносит прибыль), а всю свою карьеру трудятся "на дядю", в крупных компаниях. Эти люди, как правило, следуют корпоративным стандартам, и, если руководство или коллеги решают внедрить DDD, они следуют этим инструкциям, не оспаривая и не анализируя их применимость к конкретному проекту. Для таких специалистов важна не оптимизация проекта или конечный результат, а выполнение задачи в рамках предписанной методологии. Это часто приводит к тому, что время разработки увеличивается, проект становится сложнее в поддержке, и страдает бизнес, который мог бы достичь цели быстрее, выбрав более гибкий подход.
Третий тип — это конкуренты, которые используют DDD как инструмент для торможения развития других компаний. Пропагандируя идею о том, что DDD нужно внедрять повсеместно, невзирая на потери времени и прибыли, они сознательно усложняют жизнь своим соперникам. DDD действительно может замедлить процесс разработки, особенно если компания еще не готова к такой глубокой перестройке своих подходов. Поэтому конкуренты могут активно продвигать DDD в надежде, что их оппоненты застрянут в сложных технических дебрях, в то время как они сами будут двигаться более гибко и быстро, применяя другие методологии.
Таким образом, без глубокого понимания и осмысленного подхода DDD может стать тормозом для бизнеса. Следование одной методологии, как DDD, без критического анализа приводит к тому, что проект усложняется, затягиваются сроки, а в конечном счете и снижается прибыль. Более рациональный подход заключается в том, чтобы комбинировать элементы различных методологий, подбирая решения, которые наилучшим образом соответствуют конкретным бизнес-задачам, а не слепо следовать какой-то одной популярной концепции.
Комментарии