Сейчас, самым передовым, модным и современным способом проектировать системы на теоретическом уровне является DDD - Domain Driven Design.
Что это такое и как им пользоваться никто нормально не знает. Но многие задокументированные попытки вы можете найти в интернете.
Почему я утверждаю, что никто нормально не знает? Потому что, формально, DDD это та же жвачка для ума для лидов и архитекторов, как и Haskell для студентов. Очень интересно попробовать с ней поиграть, попроектировать, попрограммировать. Особенно, когда ты только прочитал о такой методологии. Но те подходы, которые используются в основе методологии тратят самый важный ресурс - время.
Пока вы будете проектировать и углубляться вглубь домена, изобретать идеальные связи и системы, подходящие конкретной компании и их орг-структуре, пройдет квартал. Потом ещё два квартала вы будете программировать решение, и хорошо если рефакторигом текущего. Если вы будете строить отдельную коробку - это займет ещё больше времени, из-за миграции и внедрения. И вот, вы уже запустили идеально спроектированное решение. Но бизнес все равно не доволен, потому что ситуация на рынке уже не та, конкуренты сделали подобное на полгода раньше, а важные проекты были отложены.
На моей практике, и вообще по тем видимым признакам, как работает современный бизнес, я для себя сделал вывод, что ДДД показывает себя не очень эффективно в окружении, когда вокруг стартап процессы. Когда бизнесу хочется сократить время поставки продуктов до клиентов, посчитать цифры и эффективность запуска. И уже после, возможно, сделать правильно. А если не взлетит - закопать и пойти делать новое. Пока большие дяди будут рисовать UML диаграммы на долгих совещаниях, не обремененные субординацией команды проверят десяток гипотез.
Но все же, как мне кажется, ДДД все же полезен. Полезен не столько для проектирования, сколько для поддержания структуры проектов и прозрачности процессов в системах. Методология заставляет всех участников разработки, а так же иногда и бизнеса, начать называть всё своими именами. Особенно в больших командах, для поддержания эффективности, всем приходится следовать правилам. На всех этапах процессов выделяются сущности и эти сами процессы начинают четко обозначаться. Это вносит некоторую бюрократию и духоту в рабочие коммуникации, но снижает вероятность мисскоммуниации.
Так же, использование принципов ДДД провоцирует разработчиков использовать стандартные подходы к организации кода, что в свою очередь, помогает новеньким быстрее погружаться в процессы.