Всегда ли хороша модульная организация архитектуры проекта?
Поясню немного суть вопроса.
Есть очень много «классики» по поводу организации MVC парадигмы.
Есть парадигма HMVC (впервые встретил, когда работал с CodeIgniter). Суть примерна та же, только выделяем модули, внутри которых строим MVC модель. Мне кажется, что это достаточно известный подход (и логичный), но не все знакомы с таким термином (может быть есть другие, не суть в данном контексте).
По долгу службы / работы над проектом, столкнулся со сложностью выделения сущностей в отдельные модули. Проект представляет собой весьма связанный процесс. Если отбросить все ньюансы, то этот процесс можно назвать «документооборот, завязанный на различные бизнес-процессы».
Сложность заключается в том, что очень сложно выделить «вариативные» модули, либо отключить какой-то модуль. В текущей завязке процесс просто перестанет быть непрерывно и сойдет на нет. А соответственно, система перестанет быть жизнеспособной.
Небольшое исследование и террор друзей дал весьма интересную пищу для ума: достаточно много крупных проектов реализуют «архитектуру сервисов»: вводится ограничение на «общение» между разными сущностями напрямую. Само общение организуется через сервис — шлюз и / или другой аналогичный инструментарий (API / SOAP / JSON / XML). Также вводится понятие «статуса» сообщения / движения процесса. В зависимости от него, определяется «местоположение» в бизнес-процессе.
«Вариаторы» вводятся за счет частичного дублирования кода. Адресация к ним — за счет введения доп статусов.
Поток бизнес-процесса может определяться маппингом (в случае, если необходимо реализовать альтернативные пути движения данных. Например, при определенном стечении обстоятельств, мы не выполняем какую-то часть логики, а отправляем запрос на сторонний сервис, а дальше ловит ответ и переводим в третий статус).
Буду признателен доп информации о таком подходе, может быть подводные камни, которые следует учесть, что почитать на этот счет (и как это правильно называется :) )
Ну все зависит от технического задания. Если система запланирована на дальнейшую интеграцию с другими продуктами, либо является коробочным решением, то конечно же можно сделать ее модульной, с возможностью заменять части системы сторонними компонентами. Если же нет — то на разработку, тестирование, отлаживание такой модульной системы вы потратите драгоценное время, которого у вас уже не будет хватать, чтобы вовремя завершить проект.
По своему опыту могу сказать, что одна из самых больших проблем, с которой я встречался — это распределенные транзакции, когда один «запрос» затрагивает сразу несколько сервисов, и в случае краха одного из них необходимо откатить все изменения. Из-за отсутствия поддержки распределенных транзакций нам постоянно приходилось подчищать все вручную. Если будете делать сервисно-ориентированное ПО, то обязательно продумайте, как вы будете фиксировать или откатывать изменения, обязательно применяйте интеграционные тесты на ошибочных данных и проверяйте правильность работы системы.
MVC по максимуму направлен на отвязку BI от UI. У вас задача, как я понимаю, сложнее чем UI для обработки данных. Читайте DDD, почти уверен, что это то, что вам нужно.
По поводу Разделения ответственности — очень интересная штука.
А вот нейронные сети — немного не то :) информация полезная и нужная мне, но не контексте этого вопроса )
Спасибо за мнение. Но тут вопрос возник не на ровном месте. И причина не в том, что «хочу экспериментов».
Меняются требования, и продукт, в очень схожем виде нужно будет внедрять в другие организации.
Если не организовать единой системы, то прийдется делать 2 разных продукта (и это количество со временем будет увеличиваться).
Цена поддержки для этого продукта весьма существенна. Поэтому и в поисках архитектурного решения, которое позволит расширить систему в N раз минимально болезненно для неизменного количества разработчиков :)
Поскольку код проекта не видел точно ничего сказать не смогу, но попробуй использовать больше функций вынесенных в отдельные библиотеки. Функции которые являются базовыми заносить библиотеки взаимодействия. На стадии внедрения потребуется только компиляция нужных элементов:
Элементы:
Программа — база.
Базовая библиотека — базовый модуль определяющий взаимодействие между элементами.
Библиотека «модуль1»
Библиотека «модуль2»
Библиотека «модуль3»
Библиотека «модуль4»
Компилируем:
Программа
Базовая библиотека
Библиотека «модуль2»
Библиотека «модуль4»
И все. Система легко расширяется за счет наращивания модулей. Вообще это дело вкуса, но я бы писал систему именно так.
Средний
