KIT

В прошлом посте мы разобрали классический вариант реализации Active Record. Обсудили, когда стоит переходить от Transactional Script к Active Record. Сегодня обсудим: 📌 Внутри Active Record помещайте только простые инварианты: проверки статусов, ограничения значений, пересчет полей, базовые проверки. 📌 Не включайте сложную бизнес-логику: расчёты цен с кучей правил, сложные жизненные циклы. Для этого уже нужен Domain Model. 📌 Избегайте анемии: не делайте getters/setters публичными без необходимости...

В прошлом посте мы разбирали Transactional Script - отличный инструмент для старта. Но любой проект развивается. Со временем вы начинаете замечать, что Transactional Script становится сильно усложненным. В них добавляются простые бизнес-инварианты, дополнительные проверки и сами структуры данных становятся довольно сложными. Скрипт перестает быть читабельным, занимает несколько экранов, а логика начинает дублироваться. Кажется, что самое время достать "тяжелую артиллерию" из Domain Driven Design - паттерн Domain Model...

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

Сегодня мы рассмотрим паттерн Transactional Script — пожалуй, самый популярный и наиболее старый подход к организации бизнес-логики в приложениях. В простых сценариях и контекстах Domain Driven Design именно он будет часто и широко использоваться. Этот паттерн был впервые формально описан Мартином Фаулером в его книге Patterns of Enterprise Application Architecture (2002), хотя самим подходом разработчики пользуются столько же, сколько существует программирование. Фаулер каталогизировал его как один из основных способов организации логики в корпоративных приложениях...

Около 20% проектов терпят провал. От них отказываются или забрасывают еще до старта (по данным Standish Group’s CHAOS study). И только около 30% проектов действительно успешны — укладываются в сроки, бюджеты и оправдывают ожидания. Это происходит по множеству причин, часто даже по совокупности. Одна из причин — «full-scale» старт, когда на старте проекта мы собираем большую готовую команду, и она начинает потреблять бюджеты как черная дыра. Давайте разберемся подробнее, почему так происходит. Даже...

В мире распределенных систем существует множество подходов к управлению процессами и согласованностью данных. Часто для управления согласованностью применяют подходы, предназначенные для управления процессами, и наоборот. Часто вследствие неправильного применения подходов распределенные системы становятся неуправляемыми. Один из источников путаницы - смешивание Saga и Process Manager. Давайте разберемся чем они концептуально отличаются. Saga - паттерн управления согласованностью данными и транзакциями в распределенных системах...

Итак, мы приняли решение использовать подход Domain Driven Design для реализации нашего приложения. Мы собрали экспертов доменной области. Провели несколько сессий Event Storming. Выделили основные события, агрегаты, нарисовали карты контекстов и приступили к реализации. Теперь перед нами возникают вопросы: ➤ Как реализовать код и логику наших модели? ➤ Какие есть варианты и подходы к имплементации бизнес-логики? ➤ Всегда ли надо использовать паттерн Domain Model? Давайте разберемся... В своей книге...

В распределенных системах, помимо задач управления данными и транзакциями, существуют задачи управления самими процессами. Бывают сложные сценарии с множеством ветвлений, условиями, повторными попытками, откатами и длительными ожиданиями. В таких случаях уже невозможно либо очень трудно использовать простые цепочки вызовов и реакцию на события, это быстро превращает нашу систему в «спагетти» — запутанную, хрупкую и неподдающуюся тестированию. На помощь приходит паттерн Process Manager. Process Manager...

Когда мы слышим Domain Driven Design, на ум сразу приходят такие понятия, как Ubiquitous Language (Повсеместный/Всеобщий язык), Bounded Contexts (Ограниченные контексты), то есть чаще всего говорят о стратегическом дизайне. Но между стратегией и кодом лежит большой очень важный слой — тактический дизайн. Это то, как стратегические идеи воплощаются в конкретные и работоспособные программные модели. Тактический дизайн — инструмент моделирования Bounded Context. Этой части DDD незаслуженно уделяют мало внимания, хотя без тактики любая стратегия терпит поражение...

В мире микросервисов есть одна вечная проблема: как обеспечить согласованность данных между независимыми компонентами? Традиционные транзакции здесь не работают, но есть элегантное решение — Saga-паттерн. Разберем, откуда он произошел, что из себя представляет и почему стал стандартом индустрии. Saga — паттерн управления данными и транзакциями в распределенных системах. Вместо одной большой транзакции, когда весь процесс либо завершен, либо откатывается, данный паттерн разбивает весь процесс на несколько локальных транзакций...

Кэш — механизм, который часто используют как «волшебную кнопку» для ускорения системы — достаточно добавить Redis, и всё работает быстрее. Есть обманчивое восприятие механизма кэширования — будто мы можем радикально изменить производительность системы, снизить затраты на инфраструктуру и даже повлиять на бизнес-метрики. Почти в каждом проекте наступает момент, когда кто-то говорит: «Давайте просто закэшируем». Обычно после этого система становится быстрее — и одновременно сложнее, опаснее и менее предсказуемой...

Всем привет! Сегодня хочу коснуться такого понятия Domain Driven Design как модель. В подходе DDD мы говорим о моделировании бизнес-процессов в коде системы. Существуют различные мнения и заблуждения на этот счет. Давайте разберемся, а что же, по своей сути, называется моделью. Модель — это ограниченное и упрощенное представление реального объекта или явления. Которое сохраняет те свойства оригинала, которые важны для исследования. Модель —это представление в воображении, в виде математических, физических, графических или символических форм...