Как стать автором
Обновить

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

Разработка веб-сайтов *Ruby *Анализ и проектирование систем *Проектирование и рефакторинг *Ruby on Rails *
Всего голосов 9: ↑9 и ↓0 +9
Просмотры 14K
Комментарии 4

Комментарии 4

Автор, очень важная тема на самом деле. Такой подход реально помогает эффективно разрабатывать большие системы в команде. В общем, пиши ещё!

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


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


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


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

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


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


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


Впечатление сложилось правильное :)


  1. Из-за того, что бизнес-логика уходит в ServiceObjects, тесты для ServiceObjects выглядят как описание бизнес логики. И это очень и очень удобно. Писать на русском удобно, особенно если термины существуют только на русском языке. Бизнес вряд ли будет смотреть тесты, если у вас не IT компания. Но если вы смогли их заставить это сделать, вы очень круты :)
  2. Так и есть. И зачастую все называют лошадью. И кобыл, и жеребцов и коров =)
  3. На 180 градусов развернутся не получится, это решение не для MVP. Но всяческие корректировки проходят в разы быстрее. По-большому счету если изменился процесс — переписываем только ServiceObject, изменился порядок процессов — меняем Interactor. И из-за слабой связанности классов, не боимся, что у нас что-то рассыпаться в другом месте.
  4. Согласен. Если смотреть на всякие старые методологии, вроде RUP, то в них, деятельность IT воспринималась как автоматизация документооборота. А результатом любой хоз. деятельности бизнеса являлся документ. А оборот это как раз связки, унификация и выстраивание потоков.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.