Всегда ли хороша модульная организация архитектуры проекта?

Поясню немного суть вопроса.


Есть очень много «классики» по поводу организации MVC парадигмы.

Есть парадигма HMVC (впервые встретил, когда работал с CodeIgniter). Суть примерна та же, только выделяем модули, внутри которых строим MVC модель. Мне кажется, что это достаточно известный подход (и логичный), но не все знакомы с таким термином (может быть есть другие, не суть в данном контексте).


По долгу службы / работы над проектом, столкнулся со сложностью выделения сущностей в отдельные модули. Проект представляет собой весьма связанный процесс. Если отбросить все ньюансы, то этот процесс можно назвать «документооборот, завязанный на различные бизнес-процессы».


Сложность заключается в том, что очень сложно выделить «вариативные» модули, либо отключить какой-то модуль. В текущей завязке процесс просто перестанет быть непрерывно и сойдет на нет. А соответственно, система перестанет быть жизнеспособной.


Небольшое исследование и террор друзей дал весьма интересную пищу для ума: достаточно много крупных проектов реализуют «архитектуру сервисов»: вводится ограничение на «общение» между разными сущностями напрямую. Само общение организуется через сервис — шлюз и / или другой аналогичный инструментарий (API / SOAP / JSON / XML). Также вводится понятие «статуса» сообщения / движения процесса. В зависимости от него, определяется «местоположение» в бизнес-процессе.


«Вариаторы» вводятся за счет частичного дублирования кода. Адресация к ним — за счет введения доп статусов.

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


Буду признателен доп информации о таком подходе, может быть подводные камни, которые следует учесть, что почитать на этот счет (и как это правильно называется :) )


Заранее спасибо.
  • Вопрос задан
  • 3280 просмотров
Пригласить эксперта
Ответы на вопрос 5
@SergeyGrigorev
Ну все зависит от технического задания. Если система запланирована на дальнейшую интеграцию с другими продуктами, либо является коробочным решением, то конечно же можно сделать ее модульной, с возможностью заменять части системы сторонними компонентами. Если же нет — то на разработку, тестирование, отлаживание такой модульной системы вы потратите драгоценное время, которого у вас уже не будет хватать, чтобы вовремя завершить проект.
Ответ написан
kuzemchik
@kuzemchik
MVC по максимуму направлен на отвязку BI от UI. У вас задача, как я понимаю, сложнее чем UI для обработки данных. Читайте DDD, почти уверен, что это то, что вам нужно.
Ответ написан
EugeneOZ
@EugeneOZ
Да.
Подтверждено миллионами лет эволюции: lenta.ru/news/2012/07/16/modulenet/
Вынесено в один из фундаметнальных принципов инжинерного дела: ru.wikipedia.org/wiki/Разделение_ответственности
Ответ написан
JustLuckyGuy
@JustLuckyGuy
Пишите так, как удобно вам и потом небыло стыдно. Это главный подход :)
Ответ написан
astrobeglec
@astrobeglec
Поскольку код проекта не видел точно ничего сказать не смогу, но попробуй использовать больше функций вынесенных в отдельные библиотеки. Функции которые являются базовыми заносить библиотеки взаимодействия. На стадии внедрения потребуется только компиляция нужных элементов:
Элементы:
Программа — база.
Базовая библиотека — базовый модуль определяющий взаимодействие между элементами.
Библиотека «модуль1»
Библиотека «модуль2»
Библиотека «модуль3»
Библиотека «модуль4»
Компилируем:
Программа
Базовая библиотека
Библиотека «модуль2»
Библиотека «модуль4»
И все. Система легко расширяется за счет наращивания модулей. Вообще это дело вкуса, но я бы писал систему именно так.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы