Пользователь
В данной статье мы погрузимся в мир DDD, сфокусировавшись на самом важном аспекте – модульности. Разберем стратегические паттерны, предоставляющие необходимые инструменты для эффективной организации модульности на уровне организации. Обсудим, как определить границы между контекстами, установить правила взаимодействия и эффективно управлять сложностью в разработке крупных бизнес-приложений.
Привет, Хабр!
Сегодня мы поговорим о двух концепциях — Event Sourcing и CQRS, и их реализации на языке Go. Go предоставляет хорошие возможности для реализации этих паттернов благодаря своей производительности, простоте и поддержке конкурентности «из коробки».
Добиться, чтобы приложение в равной степени могло управляться пользователями, программами, автоматизированными тестовыми или пакетными сценариями, а также разрабатываться и тестироваться в изоляции от устройств и баз данных, на которых оно впоследствии будет выполняться. — Алистер Кокберн, 2005 г.
Проектирование REST API - это процесс создания дизайна методов обмена данными. Дизайн - это субъективное. У одних "так", у других "сяк". А кто прав? Иногда все, а иногда нет.
Можно ли сделать в проекте все методы POST? Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)? Можно ли использовать метод POST для получения данных? ...
Холиварные вопросы! Вкусовщина! Давайте разбираться!
Делюсь опытом по становлению каршеринга на светлую сторону Силы — переезду в облако.
Мы переезжали из одного датацентра в другой, шатали прод по ночам, выкатывали новые микросервисы, переписывали старые, наш парк машин вырос в 4 раза. И всё это за экстремальные 2 года!
Привет! Меня зовут Олег Мифле. Одной из команд, где удалось поработать за 7 лет с PHP, стала Customer Support. Мы автоматизировали анализ тысяч задач в день и оператору больше не нужно думать и включать голову для того, чтобы понять, какая задача прямо сейчас важна. О том, как работает приоритизация и что такое дерево игры, расскажу в статье.
На старте погружу в предметную область. Она непростая, но постараюсь быстро. Эта статья по моему докладу с PHP Russia 2022. Вот запись.
Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.
Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.
Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.
Мы занимаемся разработкой огромного количества сложного ПО для автоматизации и энтерпрайза и Workflow для нас — это большая и больная проблема. Если для вас тоже — я расскажу, как писать и оркестрировать очень сложные процессы на масштабах, и как убедиться, что они не падают. А также как делать таймеры на 30 дней внутри процессов. И самое главное, как всё это пилить на PHP.
Меня зовут Антон Титов. Я более 17 лет занимаюсь коммерческой разработкой. Являюсь соавтором Spiral Framework, RoadRunner и Cycle ORM. Основной стек: PHP и Golang. Разговор пойдет про нашу разработку Temporal PHP SDK, которая и помогает решать все вышеперечисленные сложные задачи.
Цель этой статьи — показать не только зачем, но и как мы можем создавать приложения на PHP, которые будут устойчивыми, масштабируемыми и податливыми для изменений. Статья концентрируется на разработке бизнес-ориентированных приложений, в которых можно четко выделить бизнес-логику, процессы и потоки работ (workflows). Это квинтэссенция моего опыта, накопленного за годы работы над бизнес-ориентированным программным обеспечением в целом и в процессе создания фреймворка для обмена сообщениями Ecotone в частности.
Сборник реальных советов по написанию сопровождаемых программ на языке Go. Автор - Dave Cheney, опытный разработчик на Go и один из его ведущих пропагандистов.
В своем проекте мы столкнулись с необходимостью осуществить определенные действия с заявкой в нашей микросервисной архитектуре между несколькими сервисами. Причем если одно или несколько действий завершаются неудачно, то все следующие действия должны быть отменены, оставив состояние сущностей неизменным. Также в случае получения нефинальной ошибки мы хотели бы попробовать довести процесс до финала, не откатывая предыдущие шаги.
В монолитном приложении это было бы сделать легко, опираясь на гарантии удовлетворяющей требования ACID базы данных. В нашем же случае такой фокус не пройдет, наш бизнес-процесс затрагивает сразу несколько баз данных и брокеров сообщений, следовательно, решить эту задачу, запустив одну транзакцию, невозможно.
Поскольку наверняка не мы первые столкнулись с такой проблемой, то решили изучить существующие способы решения этой задачи.
У некоторых в команде уже был опыт работы с xa-транзакциями.
Довольно удобный способ, когда у вас есть несколько ACID СУБД. Процесс состоит из двух фаз.
Сборник реальных советов по написанию сопровождаемых программ на языке Go. Автор - Dave Cheney, опытный разработчик на Go и один из его ведущих пропагандистов.
Всем привет, меня зовут Ян Чикнизов.
Мой опыт в IT насчитывает уже 6 лет, и за эти годы я повидал множество тимлидов и техлидов, разного рода качества, и сам выступал как хорошим лидом, так и не очень. В статье хочу с вами поделиться опытом и навыками, которые помогли мне стать хорошим лидом (по отзывам коллег, конечно же).
Для этого возьмем пять конкретных ситуаций, на основе которых обсудим, как в этой ситуации будет вести себя разработчик, а какие обязанности будет выполнять тимлид. Разберёмся, как в кратчайшие сроки создать новую фичу и как потом словить аварию после её выкатки, займемся небольшим легаси-менеджментом, а также наймем новых разработчиков. Напоследок обсудим, как в очередной раз не изобрести велосипед.
В книге Криса Ричардсона «Микросервисы: паттерны разработки и рефакторинга», описывается что-то около 20 паттернов, использующихся в микросервисной архитектуре. Все они делятся на 5 больших групп: decomposition patterns, integration patterns, database patterns, observability patterns и cross-cutting concern patterns. Я, узнав про паттерны, которые могут быть применимы в микросервисной архитектуре, немного изучила их и попробовала реализовать один из них. Всем привет, меня зовут Екатерина Попкова, я Java/Kotlin-разработчик в Альфа-Банке, и хочу рассказать, как можно обеспечить консистентность данных в микросервисной архитектуре с помощью применения паттерна «Сага».
В прошлой статье я рассказал, как мы пришли к DDD и про его очень важную особенность — единый язык, на котором легче и дешевле разговаривать с бизнесом. Еще мы рассмотрели разработку, ведомую моделью. Когда вначале стоит не выполненная по требованию фича, а абстрактная модель, созданная по требованиям и имеющая отражения в различных представлениях. Все эти области оперируют терминами единого языка и реализованы максимально похожими, чтобы каждый, кто будет работать с проектом, смог разобраться в любой из них.
Сегодня поговорим о том, как приручить непосредственно исходные коды программ, как они архитектурно представляются. Расскажу про идеи, которые мы используем для построения прозрачной и понятной модели, чтобы ее было легко развивать вместе с заказчиком. Эти подходы касаются и архитектуры, и хранения исходного кода, и вообще в целом вопросов разработки. Также расскажу про практические сложности. Формат статьи не позволяет включить огромное количество кейсов, поэтому приведу только два примера.
DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.
Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.
