Надо исходить из изначального посыла - что такое хорошая архитектура и надо различать понятия дизайн и архитектура. Архитектура это высокоуровневая концепция. Это вопрос какую БД выбрать, какой прокси сервер, определение нагрузки на приложение. Так же архитектура это то сколько и какие слои в вашем приложении будут. А вот SOLID это как раз про дизайн отдельных модулей и классов. Итак. Какие изначальные постулаты "хорошего дизайна"?
- Понятность/читаемость кода
- Слабая связанность и сильная связность (зацепление) отдельных модулей
- Разделение компонентов по ответственностям
- Возможность повторного использования компонентов
- Надежность (вопрос устойчивости и корректности ПО)
Исходя из этих критериев и нужно рассматривать архитектуру приложения. Но вот так просто "с улицы" зайти в проект и понять хорошая там архитектура или плохая ИМХО нельзя. Если пресловутые принципы SOLID нарушаются в приложении, то может так и задумано? Мартин вот категорично говорит, что нельзя зависеть от конкретных реализаций. Если у вас в зависимостях есть конкретный класс, а не интерфейс, то это якобы плохой дизайн, вы нарушаете принцип SOLID. Так ли это важно и нужно? Да не особо. Если нет смысла зависеть от интерфейса, то не надо пихать его. В этом и заключается чуйка архитектора. Если он считает, что реализация меняться не будет, то не нужно усложнять код. Если он считает, что требования будут меняться и следственно реализация, то вероятно стоит защитить конкретный компонент и выделить интерфейс. Если класс на 30к строк это не значит, что там плохая архитектура. Кто-то скажет, что это вполне себе Domain Model паттерн, вместо Anemic Model и это хороший дизайн, кто-то скажет что нарушается SRP. Нет четких правил, тут именно что нужно понимать предметную область с которой работаешь и вырабатывать чуйку.
