Паттерн Command — широко известный и мощный инструмент построения гибких систем, позволяющий целиком вынести логику каждого метода в отдельный класс.
В статье показано как совмещение Command с Dependency Injection (DI) даёт дополнительные преимущества в архитектуре приложений.
Статья будет полезна разработчикам всех уровней, а также архитекторам приложений.
Привет! Я работаю на должности главного солюшн архитектора трайба в ОТП Банке. В своей работе часто сталкиваюсь с интересными архитектурными вызовами, которые возникают на стыке технологий, безопасности и бизнес-требований. Часть из них я уже описал в предыдущей статье, посвященной интеграции системы дистанционного банковского обслуживания (RBS) с бэкофисом (Event-Driven Architecture в высоконагруженном ДБО: наш опыт.)
Я хотел бы поделиться размышлениями о роли архитектора — о том, как мы ее представляем и с чем сталкиваемся на практике. Мы часто создаем вокруг этой роли определенный шарм и завышенные ожидания, которые не всегда соответствуют реальности. Это приводит к разочарованию у тех, кто приходит в профессию. Давайте поговорим об этом честно.
«Хорошо определённая проблема - это проблема наполовину решённая». Джон Дьюи.
Если в вашей практике на начальном этапе анализа проекта обозначаются все контексты и границы взаимодействия систем, то скорее всего у вас хорошо развита культура системного дизайна и данная статья для вас не имеет практического значения. В противном случае предлагаю уделить 5 минут вашего времени для ознакомления с материалом.
Агенты для программирования на базе ИИ — это не мимолётный тренд, а развивающаяся часть современного процесса разработки. Разработчикам становится всё важнее уметь эффективно использовать такие инструменты, чтобы повышать продуктивность и качество своей работы.
Большие языковые модели (LLM) не стоит воспринимать как взаимозаменяемые. Выбор модели существенно влияет на качество работы, которую выполняет агент.
Чтобы правильно задать вопрос, нужно знать большую часть ответа.
Шекли
Дисклаймер – этот текст не принесёт никакой пользы тем, кто не знает, что такое DDD, тем, кто не хочет ничего знать про DDD и тем, кто уже знает про DDD всё, что им нужно.
Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.
Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь Читать полностью »
Серия псевдофилософских мини-эссе о работе функционального архитектора.
Очень полезная практика – осознанно записывать архитектурные решения, принятые на проекте. Желательно сопровождать это описанием причин, по которым был сделан выбор в пользу принятого решения. В идеале дополнять описанием альтернативных вариантов решения, которые рассматривались, с их ключевыми плюсами и минусами.
Делать это нужно в каждой ситуации дуальности. Даже если в моменте принятое решение кажется вам очевидным.
Даже не знаю с чего начать, это моя первая статья и пишу я ее по причине того что мне не с кем обсудить ее содержимое. Для контекста добавлю, что я самоучка без работы.
Именно такое название мне дал чат гпт, когда я спросил его о моем подходе, и как он мне сообщил, то что я придумал, это уникально и (цитирую) «Годнота!». Но названия у всей этой истории нету, ибо я не силен в нейминге, но в коде она называется «MEctx». Можете предложить название, мб приживется...
Если описывать моими мыслями (а я не знаю теорию js), то получается следующее:
