Поваренная книга разработчика: Domain Driven Design рецепты ( 2-я часть, структура и взаимодействие )

Сложилось впечатление, что DDD несет в себе старый добрый подход разделяй и властвуй, с упором на коммуникацию с "бизнесом", так чтобы формулировка задачи не техническим человеком позволяла быстро определить местонахождение кода для её выполнения.

Как можно решить следующие проблемы?

1. проблема с переводом, бизнес говорит по русски, в коде все по английски, думаю что это проблему можно смягчить описанием тестов на русском

   
   

   describe OrderService::Create do
   it 'когда у пользователя есть несколько не отправленных заказов, создает уведомление об объединении'
   it 'при стоимости заказа менее 1000 доставка платная'
   end

   
   

2. На стороне бизнеса должны быть специалисты своих областей, но по факту получается что они могут называть одни и те же вещи разными словами в разные дни недели, и не могут четко сформулировать чего хотят (говорят о быстрой лошади, но мечтают о машине)

   
   

3. Rails MVC по моим ощущениям хватает на 4 человека-года, потом начинаются серьёзная посадка скорости разработки. Но первое время позволяет быстро писать код, особо не задумываясь об архитектуре (всё в модель!), возможно приложение быстрее станет не актуальным и надо делать смену бизнес модели, с DDD разворачиваться в другую сторону быстрее или медленнее?

   
   

4. Я думаю, что лучше кода приложения ничего не отражает реальности процессов в бизнесе, DDD воспринимает ИТ как придаток бизнеса, и не говорит об обратном взаимодействии — ИТ на организацию процессов в компании. Ведь ИТ может подмечать не состыковки и унифицировать словарь между отделами.

   
   

R и Spark

1. Возможно ли для алгоритмов Spark'a автоматически подбирать гиперпараметры моделей, через caret например?
2. Есть ли сохранение моделей в файл, что бы например в продакшене (где уже используется Scala) загрузить и использовать уже обученную модель?