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

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

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

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

Теперь справа нарисуйте несколько длинных прямоугольников снизу доверху и написшите в них: логирование, конфигурация, мониторинг производительности, обработка исключений и что-то ещё, что является общей инфраструктурой (или сквозной функциональностью) для всех слоёв вашей программы.

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

Вот Вы только ВУЗ закончили, и уже жалуетесь, что разработчики вокруг слабые. Что ж Вы говорить будете, когда архитектором станете? :(

Это я к тому, что (1) любое развитие начинается с личности, а не с команды, и (2) если Вы хотите достичь вершин, то работа с теми, кто слабее Вас, должна стать неотъемлемой частью Вашего бытия. И Вы должны быть этого достойны. Никто не хочет иметь в команде чванливого супергероя, но мудрый и терпеливый наставник, способный вовремя подставить плечо более слабому - это очень важная роль. Так что, если действительно хотите развиваться, в первую очередь займитесь своими личными качествами. Поверьте, они часто более важны, чем умение писать оптимальный код.

Что касается кода, то есть несколько направлений (скорее всего, этим Вам придётся заниматься в свободное время):

• читайте и экспериментируйте; вам нужен широкий кругозор и глубокие знания в ключевых областях (таких, как особенности реализации типов, производительность и т.п.);
  
• возьмите какой-то качественный проект с открытым кодом и проведите анализ кода - наверняка найдёте много интересного;
  
• займитесь фрилансом: и денюжка лишняя не помешает, и головомойки периодические от тимлидов заказчика себе обеспечите.
  

Ну и наверняка ещё что-то можно в этот список добавить. Было бы желание. А вот жаловаться - бросьте!

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