Выбор «лучшей» архитектуры - это понимание драйверов, которые стоят за решением, которое требуется. Это не то, что команда разработчиков может сделать самостоятельно - им нужно работать с бизнесом / заинтересованными сторонами, чтобы убедиться, что они понимают относительные приоритеты.
Одна из причин этого заключается в том, что вы не хотите, чтобы «архитектурно значимые» приоритеты менялись в середине потока (степень изменения, вероятно, будет слишком большой). Если вещи не будут разработаны достаточно рано, вы обнаружите основные движущие силы, когда по существу слишком поздно.
Так "как" ты это делаешь?
- Понять проблему и составить список / матрицу критериев, которые имеют отношение к делу. например:
- «Важно, чтобы пользователи могли заменять модули своими собственными реализациями, поэтому архитектура должна поддерживать модульный дизайн».
- Это может привести к: «компоненты должны заменяться во время выполнения, не переводя систему в автономный режим», поэтому архитектура должна поддерживать модули с «горячей заменой».
- Система должна будет поддерживать клиентов на настольных компьютерах и телефонах, поэтому мы должны поддерживать чистоту разделения UI и бизнес-сервисов.
- Система должна поддерживать разные платформы баз данных, поэтому доступ к данным должен быть слабо связан.
- Нефункциональные требования: какие из них важны? определить топ 3-5 и расставить приоритеты. Всегда ли безопасность важнее юзабилити? Важна ли масштабируемость - если так, должна ли наша архитектура позволять нам развертывать различные части системы на разных физических серверах?
- Вообще говоря, то, что вы пытаетесь сделать, уже было сделано - выйдите и проведите некоторое исследование: найдите эталонные архитектуры и реализации, оцените их по вашим критериям.
- Когда вы смотрите на эталонных архитекторов, просто помните, что вы можете подходить к ним разными способами - по домену (медицинский, банковский, телекоммуникационный) или по технологии (облако против web / java против .net). В TOGAF есть концепции континуумов архитектуры и решений - см. Схему и текст в разделе 9.6.1 . Он работает на идее, что где-то кто-то, вероятно, определит хорошую архитектуру, которая может хорошо подходить для вашей ситуации