Вопрос. Как правильно проектировать грамотную и легко поддерживаемую архитектуру приложения?

Ответ. Чтобы научиться проектировать архитектуру приложения — нужно начать ее проектировать. Звучит банально, но это так. При этом надо понимать, что развитие разработчика и архитектора — отличаются.

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

Требования к будущему ПО

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

Понимать те цели, которые поставлены перед клиентом и его компанией. Уметь увидеть всю картину целиком и предоставить под это ИТ решение. Другими словами — мыслить стратегически.

Ниже я приведу часть вопросов, которые задаю я, когда с командой начинаем новый проект или разрабатываем новый модуль:

  1. Что мы делаем?
  2. Как мы это должны сделать?
  3. Зачем мы это делаем?
  4. Сколько примерно пользователей планируется?
  5. Какой результат у нас должен быть на выходе?
  6. Какая степень деградации системы возможна?
  7. Как часто будут выходить обновления системы?

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

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

Архитектурные паттерны

Нужно знать какие архитектурные шаблоны (SOA, N-tier и т.д.) есть, в чем плюсы и минусы каждого. К примеру, понимать когда лучше использовать монолит, а когда лучше использовать микросервисы. Так же предусмотреть варианты горизонтального и вертикального масштабирования ПО.

Работа с базами данных

Вне зависимости от того, какой это будет проект, новый или уже существующий, вам нужно хорошо знать базы данных. Как проводить проектирование, как нормализовать, денормализовать и когда это нужно делать. Когда нужно использовать репликацию и балансировку на серверах. Уметь тюнинговать ту или иную базу данных под проект и возрастающие нагрузки. Понимать, где лучше использовать реляционную СУБД (РСУБД), а где NoSQL.

Составлять SQL запросы для получения только той информации, которая нужна пользователю. Без попыток вытащить все что только возможно. Как правило, когда получают все возможные данные из базы, то половина из них даже не будет использоватьcя на странице.

Что получается в итоге

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

Но существует ли та самая грамотная и правильная архитектура проекта?

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

Антон Чураков
Автор публикации
Антон Чураков

Работал .NET разработчиком в компании, занимающейся разработкой и внедрением системы BPM для автоматизации бизнес-процессов. На текущий момент - руководитель IT-компании «Цифровой Волк». Основное направление которой - заказная разработка ПО