Здравствуйте, Saddo, Вы писали:

S>На данный момент, так как мы не используем Domain Driven Design как таковой, вышеприведенные решения которые приняты у нас работают. Просто, в связи изучением книг по данной практике разработки и дизайна, хотелось знать что делают те кто придерживаются этой практики

S>Сейчас, используя Data Driven Design, модель имеет более 100 сущностей (исключительно анемичных, использующихся для передачи данных). При этом модель постоянно совершенствуется. Используется словарь терминов (в виде двух человек у который можно уточнить соответсвие терминов в ТЗ, с моделью %)), а так всего один человек как связка между разработчиками и бизнес экспертами заказчика. Плюсом у нас то что, аналитик занимается так же проектированием, и не далек от кода. Минус — он не один проектирует, и это все ведет к "эксперт-аналитики-проектировщики".

Я все пытаюсь убрать лишнюю сущность, а Вы опять пытаетесь ее добавить
Да, проблема вполне понятна. В Вашей компании хотят перейти от DataDD к DomainDD. Для этого необходимо перенести фокус внимания возможно большего числа членов команды с уровня реализации хотя бы на уровень модели, потому что это — ключевая точка для перехода. В первую очередь это касается сеньоров и тимлидов, потому что без них переход не удастся осуществить в принципе. Так?

Вы в первоначальном посте изложили проблемы, которые встали перед компанией или проектом при этом переходе. Эти проблемы не являются особенностью DomainDD. Любой руководитель проекта, если у него есть голова на плечах, заботится о том, чтобы команда проекта видела задачу (в Вашем случае — модель) в целом и согласовывала свою работу с этим видением. При необходимости его корректируя. Это повышает мотивацию на результат, снижает риски — в общем, сплошные плюсы, откуда не взгляни. Если же в проекте таких людей мало — то эти люди становятся перегружены со всеми вытекающими, что ведет к необходимости введения дополнительных уровней иерархии.. ну и так далее.

А теперь скажите — решение перечисленных и поправленных Вами 4-х пунктов реально приблизит Вашу компанию к переходу на DomainDD?
И что с того, что они являются общими для всех проектов? Или Вы ищете "Пятый элемент", специфичный для DomainDD, с помощью которого удастся обойтись без решения этих пунктов? Или хотя бы имеющий большее значение, чем эти четыре?