Domain-Driven Design предлагает важную пользу, но не рассказывает с порога кое о чём важном.

Однажды ваш продукт и компания в своём росте и развитии достигают момента, когда вам нужно серьёзно заняться архитектурой. Когда по-старому дальше никак.

Тут вам на помощь может прийти Domain-Driven Design. Звучит он хорошо: предметные области, модели, единый язык; наконец-то ИТ и бизнес договорятся.

Вот только есть загвоздка: среди препятствий в использовании DDD у вас будет не только сложность предметной области и ограничения стека, но кое-что неочевидное — ценности.

О ценностях ок слышать от CEO или эйчаров, но в инженерной команде отношение к самой этой теме, по моему опыту, — нейтрально-скептическое.

И даже если (вдруг) мы почему-то решили заняться ценностями с инженерным умыслом, выясняется, что тут легко скатиться в развешивание плакатов на стенах кухни в офисе и бесполезные встречи с набившими оскомину заклинаниями. На деле выясняется, что настоящие ценности живут “в курилке”, но как с этим быть, как на что-либо влиять — вообще непонятно.

Давайте поговорим о прикладной стороне ценностей. Почему без общих ценностей у вас будут проблемы с архитектурой. Как продуктовый подход помогает в работе с ценностями. И как работать с ценностями без нудного морализаторства и гуманитарного шаманства.

Надеюсь, доклад будет интересен для С-level и руководителей, в чью зону ответственности входят вопросы архитектуры. А ещё для инженеров, кто не стесняется задавать руководству неудобные вопросы и интересуется архитектурой.