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

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

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

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

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

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

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