Не знаю как дела обстоят сейчас, но лет 5-7 назад на собеседованиях было ультра-модно спрашивать про архитектурные шаблоны. Абстрактные фабрики, синглтоны, вот это все. Возможно это и хорошая разминка для ума, но ведь архитектурные шаблоны - не самоцель. Они - средство. А цель - это адекватная архитектура приложения. Не супер-сложная (чтобы коллеги не приходили в ужас от количества реверансов и условностей при чтении/написании кода), не полное ее отсутствие (никто не любит big ball of mud катающийся в тарелке со спагетти), а сбалансированная (т.е. с умеренным использованием абстракций и инкапсуляции), симметричная (все компоненты примерно одного размера, нет god objects и армии анемичных недо-компонентов) и обладающая слабым зацеплением (aka loose coupling, обожаю российскую терминологию) структура программы.

How Robusta makes Kubernetes operation better for everyone:

  1. You run into a failure scenario and write an alert & Robusta runbook.
  2. The same scenario happens again but in a different setup. You adapt the runbook
    ...and contribute it back to Robusta so that others could use it too!
  3. You change teams, departments, companies but your best runbooks stay with you -
    they are now a part of the standard Robusta distribution! Win-win! 🖤

Go check it out!

Достигнуть такой адекватной архитектуры помогает следование некоторым принципам. Например, мы должны стараться производить код с loose coupling и high cohesion (нет, даже не буду стараться перевести на русский эти термины). Еще один замечательный свод принципов - это SOLID. Четыре из пяти его постулатов применимы и за пределами объектно-ориентированной парадигмы. Любой компонент системы должен стараться не брать на себя слишком много (single-responsibility principle), быть легко расширяемым без необходимости копаться по локоть в его кишках (open–closed principle), обладать лаконичным и недвусмысленным интерфейсом (interface segregation principle) и не зависеть от конкретных реализаций соседних компонентов (dependency inversion principle). Заметьте, я умышленно не употреблял слово код в прошлом предложении, потому что более высокоуровневые компоненты (микросервисы, очереди задач, API и пр.) также должны удовлетворять этим принципам, чтобы результирующая система оказалась адекватной.

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

Навеяно недавней статьей Кента Бека Monolith -> Services: Theory & Practice.