Хранение всего слабо связанного и растяжимого: Слишком много слоев, слишком маленький ROI?

Очевидно, с этим можно перестараться, и нужно знать, «где остановиться. «добавление слоев.

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

Ничто в дизайне приложений не обходится без цены. Здесь цена повышенной сложности. Вы ВСЕГДА должны просмотреть свои варианты, прежде чем выбрать тот, который лучше всего соответствует вашим потребностям.

С учетом сказанного, я думаю, что ваш вопрос звучит немного предвзято. В реальном мире вы можете не часто видеть клиента, требующего новый тип БД, но вы можете часто видеть нового клиента, который хочет того же типа доступа к данным, что и предыдущий, но в другой БД. Дело не только в простоте изменения, но и в повторном использовании кода.

При оценке этих вещей я обычно считаю полезным взглянуть на это через призму принципа DRY и посмотреть на дублирование в вашем проекте.

Если вы используете более сложную архитектуру, чем ваш проект, вы, как правило, увидите много слоев, которые мало что делают, кроме обертывания других слоев и передачи вызовов. Это повторяется.

Если, с другой стороны, вы используете тонкую архитектуру для сложной системы, вы можете обнаружить, что создание функциональности в одной части системы не позволяет вам повторно использовать эту функциональность в другой части, заставляя вас напишите много очень похожего кода повсюду. Это повторяется.

По моему опыту, если вы проявляете бдительность в выявлении дублирования и постоянно проводите рефакторинг для его удаления, структура представится вам. Скажем, например, что вы начинаете с довольно простой архитектуры, но разбиваете все на методы, как только их нужно повторно использовать, и разбиваете методы на классы, как только их нужно повторно использовать другими классами. Тогда вы можете в конце концов понять, что ваши 13 классов помощников / менеджеров / обработчиков, которые вы написали для удаления дублирования, на самом деле выглядят так, как будто они берут на себя ответственность, которую можно было бы более четко определить, если бы она перешла на уровень обслуживания.

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

Возьмем гипотетический пример проекта. В тестах используются различные внутрипроцессные базы данных SQLite для скорости, база данных разработки на компьютере разработчика - PostgreSQL, промежуточная база данных - это единичная установка Oracle, а производственная база данных является масштабируемой, очень дорогой и очень сложной для настройки Oracle. кластер.

Как бы вы это реализовали, не отделяя уровень SQL от бизнес-уровня?

Это недавняя тенденция, и менее опытные лидеры / архитекторы становятся жертвами того, что подпрыгивают.

В проекте, над которым я работаю, доступ к данным шел:

Интерфейс службы -> Реализация службы -> Интерфейс делегата -> Реализация делегата -> Интерфейс DAO -> Реализация DAO -> Ibatis XML.

Это было (и есть!) Плохо в нашем случае, потому что большая часть кода в любом методе реализации делегата состояла из одной строки; он просто назвал DAO. Для каждого DAO у нас было два дополнительных класса и одна дополнительная конфигурация bean, и мы ничего от этого не получили.

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