SOA: Общие для всех подсистем модули с специфичной функциональностью нужно выделять в небольшие независимые артифакты с собственным циклом разработки и деплоем с органиченными связями с DB и интерфейсами наружу по Rest/Soap/Db.
Пример: TepmlateSerivice, MailService, ReportService, 1C-IntegrationService, SmsService.
Для целых подсистем ERP (CRM, WMS, ECM, ..) этот способ не подходит из за сильной взаимосвязи на уровне бизнес логики в общей части и общей базы.
Попытка вести раздельно по подсистемам миграцию базы и отслеживания зависимостей с общей частью будет крайне сложной задачей.
Разделение базы (каждая подсистема имеет собственную базу) и общение с общей частью по некоторому API + связь сущностей на уровне бизнес логики приведет к
большому усложнению разработки и применению распределенных транзакций, что влечет дополнительные сложности (что оправданно для очень больших приложений или когда модульность более приоритетна,
чем простота-скорость разработки).
Поэтому предлагаю подход- реализацию подсистем в виде отдельных модулей, которые можно включать-исключать из общего приложения, но сборка и деплой будут идти как один общей артифакт.
Случай когда одна подсистема уже готова, а вторая - нет, нужно учитывать при планировании релиза (что туда войдет, а что нет).
Трудоемкую функциональность, которая не может быть включена в следующий релиз нужно разрабатывать в отдельной ветке.
Общая функциональность для всего проекта (система прав, комментарии, вложения, отправка почты) должна быть ОБЩЕЙ для всех подсистем и имплементироваться один раз.
Решения по технической реализации требуемого функционала должен принимать архитектор. Спорные вопросы обсуждаются вместе но приоритет должен быть за решениями, котрое проще имплементировать и поддерживать. Общие решения на все случаи хороши на бумаге, но на практике или ведут к чрезмерным усложнениям и большим задержкам в работе приложения.
Перед постановкой задачи исполнителю должно быть архитектурное ревью.
Вариант - отдать младшему разработчику- сделай как нибудь, лишь бы работало- стоит очень дорого, когда приходится все переделывать.
Ему нужно ставить задачу- что и главное -КАК это делать.
После исполнения задачи (еще лучше- во время исполнения) должен быть контроль- КАК это делается, все ли понято.
И наоборот- если задачу выполняет квалифицированный разработчик, он должен ОБЪЯЗАТЕЛЬНО участвовать в обсуждении архитектуры.
Хороший вариант для продукта (но иногда слишком дорогой) - архитектор-старший разработчик в одном лице- самостоятельно реализует сложные задачи.
Ревью кода для тривиальных задач производится между разработчиками в парах- таким образом повышается общий уровень компетенции.
Контроль по часам- кто сколько сделал- тупиковый путь. По человеку видно- справляется ли он с работой или нет.
Дешевые разработчики обходятся очень дорого, можно брать без большого опыта- например студентов, но-толковых.
Фраймворк на основе которого пишется продукт- это только инструмент, каким бы он умным и обширным не был.
Самое важное при начальном проектировании- на основе выбранного фреймворка- сделать каркас самого приложения.
Т.е что мы храним в контексте, как запросы передаются на сервер и цепочка их обработки, как объекты трансформируются, абстрактный слой для работы с базой, переключение между подсистемами, связь между модулями, кэширование на сервере и клиенте.
Трудоемкость первой версии- порядка 2-3х недель высококвалифицированного труда.
Только после готового каркаса можно навешивать на него какую-то функциональность- привлекать разработчиков.
Идеально, когда каркас дает только один простой готовый путь для решения типовой задачи. И особенно в первое время необходимо тщательно следить,
чтобы никто не протоптал себе тропинку с заднего хода. Каркас- тоже живой и он меняется- но при этом вариант для имплементации должен оставаться один.
По моим наблюдениям в проекте на создание боле-менее устойчивого каркаса приложения уходит около полугода.
Если при этом отсутствует строгий контроль- приложение начинает разваливаться.
Однородность архитектуры соотносится с необходимым количеством человек для выполнения одной задачи от начала до конца (база-UI), или,
то же самое- сред разработки для поиска интересующего объекта.
Идеально когда разработка требует одного разработчика на одну типовую задачу (я не говорю что не может быть специализаций по технологиям, в любое время разработчик может консультироваться у коллег).
В противном случае срок выполнение задачи становиться непредсказуемым а рефакторинг систему- ужасом на крыльях ночи.