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» старт, когда на старте проекта мы собираем большую готовую команду, и она начинает потреблять бюджеты как черная дыра. Давайте разберемся подробнее, почему так происходит. Даже...