#domaindriven_design — Public Fediverse posts

Feature Based Clean Architecture. Часть 5: Масштабирование FBCA и теоретико-графовый анализ зависимостей

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

https://habr.com/ru/articles/1038450/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #Теория_графов #Масштабирование #DAG #DomainDriven_Design

Feature Based Clean Architecture. Часть 4: FBCA: формализация границ ответственности в NestJS-модуле

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

https://habr.com/ru/articles/1038438/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #DomainDriven_Design #Слоистая_архитектура #Рефакторинг #SOLID

Я строю AI-бот для самопознания. Вот спек, архитектура и почему LLM — это периферия, а не ядро

Статья четвертая из серии. Были исследование , личная история , продуктовый инсайт . Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.

https://habr.com/ru/articles/1027210/

#event_sourcing #domaindriven_design #AI_бот #архитектура #TypeScript #PostgreSQL #LLM #мессенджер_бот #саморазвитие #инварианты

Я строю AI-бот для самопознания. Вот спек, архитектура и почему LLM — это периферия, а не ядро

Статья четвертая из серии. Были исследование , личная история , продуктовый инсайт . Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.

https://habr.com/ru/articles/1027210/

#event_sourcing #domaindriven_design #AI_бот #архитектура #TypeScript #PostgreSQL #LLM #мессенджер_бот #саморазвитие #инварианты

Я строю AI-бот для самопознания. Вот спек, архитектура и почему LLM — это периферия, а не ядро

Статья четвертая из серии. Были исследование , личная история , продуктовый инсайт . Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.

https://habr.com/ru/articles/1027210/

#event_sourcing #domaindriven_design #AI_бот #архитектура #TypeScript #PostgreSQL #LLM #мессенджер_бот #саморазвитие #инварианты

Я строю AI-бот для самопознания. Вот спек, архитектура и почему LLM — это периферия, а не ядро

Статья четвертая из серии. Были исследование , личная история , продуктовый инсайт . Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.

https://habr.com/ru/articles/1027210/

#event_sourcing #domaindriven_design #AI_бот #архитектура #TypeScript #PostgreSQL #LLM #мессенджер_бот #саморазвитие #инварианты

DDD в Go без красивых схем: как один платеж получил три курса валют

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем. Читать статью

https://habr.com/ru/articles/1025226/

#ddd #domaindriven_design #go #golang #архитектура #value_object #aggregate_root #платежи #курсывалют #decimal

DDD в Go без красивых схем: как один платеж получил три курса валют

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем. Читать статью

https://habr.com/ru/articles/1025226/

#ddd #domaindriven_design #go #golang #архитектура #value_object #aggregate_root #платежи #курсывалют #decimal

DDD в Go без красивых схем: как один платеж получил три курса валют

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем. Читать статью

https://habr.com/ru/articles/1025226/

#ddd #domaindriven_design #go #golang #архитектура #value_object #aggregate_root #платежи #курсывалют #decimal

DDD в Go без красивых схем: как один платеж получил три курса валют

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем. Читать статью

https://habr.com/ru/articles/1025226/

#ddd #domaindriven_design #go #golang #архитектура #value_object #aggregate_root #платежи #курсывалют #decimal

Асинхронная архитектура на CQRS: гайд по внедрению в 2026 году

Монолит тормозит, бизнес требует новых отчётов, а каждая правка ломает всё вокруг? Знакомо! В этой статье рассматриваются примеры внедрения CQRS и Event Sourcing. разбираются практики разделения команд и запросов, построение асинхронной архитектуры на Kafka. Под катом — код, Mermaid-схемы и best practices, которые реально работают.

https://habr.com/ru/companies/otus/articles/994156/

#ddd #CQRS #DomainDriven_Design #Event_Sourcing #асинхронная_архитектура #микросервисы #Java #Apache_Kafka

Асинхронная архитектура на CQRS: гайд по внедрению в 2026 году

Монолит тормозит, бизнес требует новых отчётов, а каждая правка ломает всё вокруг? Знакомо! В этой статье рассматриваются примеры внедрения CQRS и Event Sourcing. разбираются практики разделения команд и запросов, построение асинхронной архитектуры на Kafka. Под катом — код, Mermaid-схемы и best practices, которые реально работают.

https://habr.com/ru/companies/otus/articles/994156/

#ddd #CQRS #DomainDriven_Design #Event_Sourcing #асинхронная_архитектура #микросервисы #Java #Apache_Kafka

Асинхронная архитектура на CQRS: гайд по внедрению в 2026 году

Монолит тормозит, бизнес требует новых отчётов, а каждая правка ломает всё вокруг? Знакомо! В этой статье рассматриваются примеры внедрения CQRS и Event Sourcing. разбираются практики разделения команд и запросов, построение асинхронной архитектуры на Kafka. Под катом — код, Mermaid-схемы и best practices, которые реально работают.

https://habr.com/ru/companies/otus/articles/994156/

#ddd #CQRS #DomainDriven_Design #Event_Sourcing #асинхронная_архитектура #микросервисы #Java #Apache_Kafka

Асинхронная архитектура на CQRS: гайд по внедрению в 2026 году

Монолит тормозит, бизнес требует новых отчётов, а каждая правка ломает всё вокруг? Знакомо! В этой статье рассматриваются примеры внедрения CQRS и Event Sourcing. разбираются практики разделения команд и запросов, построение асинхронной архитектуры на Kafka. Под катом — код, Mermaid-схемы и best practices, которые реально работают.

https://habr.com/ru/companies/otus/articles/994156/

#ddd #CQRS #DomainDriven_Design #Event_Sourcing #асинхронная_архитектура #микросервисы #Java #Apache_Kafka

Декомпозиция микросервисов: 5 паттернов против распределённого монолита

Микросервисы на схемах выглядят стройно, но в проде часто вырождаются в распределённый монолит: общая БД, синхронные цепочки вызовов и каскадные падения. В этой статье разберемся, как проводить границы сервисов так, чтобы система оставалась автономной — почему декомпозиция по слоям ломает независимость, как опираться на bounded context и бизнес-возможности, как аккуратно выводить legacy через Strangler, и где на практике помогают Database per Service, CQRS и Saga.

https://habr.com/ru/companies/otus/articles/994140/

#Микросервисы #Декомпозиция #Распределённый_монолит #DomainDriven_Design #Паттерны_проектирования #Saga #Архитектура_ПО

Байки про тактические паттерны DDD

Если вы никогда не интересовались паттернами DDD или это было давно и неправда, эта статья, к сожалению, мало чем сможет вам помочь. Если вы никогда не читали Вернона – я настоятельно рекомендую это сделать, его объяснения прекрасны, подробны и системны. Если же вы знакомы с трудами классиков, но сочли их оторванными от жизни, либо были когда-то ими воодушевлены, попробовали воплотить их идеи на практике, но столкнулись с проблемами и разочаровались, то, возможно, я смогу вам помочь. Не потому что я – лучший в мире архитектор, программист или технический писатель, а потому, что я применяю Domain Driven Design на практике и советы, которыми я хочу поделиться, это не « ещё один пересказ Эванса », а отражение того, как это действительно может работать (как минимум в моей практике) в реальных проектах.

https://habr.com/ru/articles/933588/

#domaindriven_design #repository #архитектура

Про архитектуру приложений для тех кому мало Чистой архитектуры

Помню, когда я был джуном и даже миддлом, меня очень волновал вопрос: как же должна выглядеть структура приложения по умным книжкам и всяким бест-практисам. На тот момент я уже повидал разные варианты архитектур, и все они выглядели корявыми, нелогичными, возникшими спонтанно из чьих-то костылей. Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура - это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке. Впрочем, эта статья для тех, кому этого не достаточно: для тех, кто хочет глубже понимать эволюцию мысли в области дизайна приложений, основные вызовы и идеи. Раньше мы в 3 частях [ 1 , 2 , 3 ] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.

https://habr.com/ru/articles/931866/

#ООП #функциональное_программирование #рефакторинг #гексагональная_архитектура #шаблоны_проектирования #структурный_дизайн #yagni #domaindriven_design

Сказание о стратегических паттернах DDD

Когда-то давно, впервые познакомившись с паттернами DDD, я подумал, что эта методология, очевидно, создана теоретиками, изрядно оторвавшимися от реальности. Себя, естественно, я считал опытным практиком. Прошли годы, прежде чем я осознал, что это Эванс был практиком, практиком создания сложных систем с большим временем жизни, а теоретиком в этой области был как раз я. В этой статье не будет примеров кода и конкретных архитектурных приёмов. Но если, читая книги и статьи по Domain Driven Design, вы недоумеваете « зачем это всё вообще », возможно, у меня есть для вас ответ. Правда, боюсь, что он вам не особо понравится.

https://habr.com/ru/articles/929070/

#domaindriven_design #архитектура_приложений

Domain-Driven Design: чистый подход к проектированию бизнес-логики

Недавно наша команда столкнулась с новым проектом — крупной backend-системой, которую руководство решило реализовать в формате монорепозитория. Масштаб бизнес-логики оказался огромным, и быстро стало понятно, что без четкой архитектурной дисциплины невозможно поддерживать читаемость, изолировать бизнес-логику и эффективно управлять сложностью. Поэтому мы выбрали подход Domain-Driven Design (DDD), при котором домен описывает бизнес-правила, а оркестратор и инфраструктура вынесены в отдельные слои. Меня зовут Рамиль Куватов, я разработчик в VK Tech, и эта статья — попытка описать и систематизировать принципы, которые помогают нам сохранять архитектуру чистой, а систему — устойчивой к изменениям.

https://habr.com/ru/companies/vk/articles/913886/

#vk_cloud #ddd #domaindriven_design #vk_tech

C#, Кодогенерация и DDD. Часть 2 — Получаем данные и пробуем генерировать

Это - вторая публикация в серии DDD и кодогенерация. ( первая часть ) В этой части мы научимся получать данные через рефлексию и Roslyn в одинаковой форме. А атрибуты из Roslyn - как объекты.

https://habr.com/ru/articles/921552/

#c# #c#net #roslyn #domaindriven_design #code_generation

C#, Кодогенерация и DDD. Часть 2 — Получаем данные и пробуем генерировать

Это - вторая публикация в серии DDD и кодогенерация. ( первая часть ) В этой части мы научимся получать данные через рефлексию и Roslyn в одинаковой форме. А атрибуты из Roslyn - как объекты.

https://habr.com/ru/articles/921552/

#c# #c#net #roslyn #domaindriven_design #code_generation

C#, Кодогенерация и DDD. Часть 2 — Получаем данные и пробуем генерировать

Это - вторая публикация в серии DDD и кодогенерация. ( первая часть ) В этой части мы научимся получать данные через рефлексию и Roslyn в одинаковой форме. А атрибуты из Roslyn - как объекты.

https://habr.com/ru/articles/921552/

#c# #c#net #roslyn #domaindriven_design #code_generation

C#, Кодогенерация и DDD. Часть 2 — Получаем данные и пробуем генерировать

Это - вторая публикация в серии DDD и кодогенерация. ( первая часть ) В этой части мы научимся получать данные через рефлексию и Roslyn в одинаковой форме. А атрибуты из Roslyn - как объекты.

https://habr.com/ru/articles/921552/

#c# #c#net #roslyn #domaindriven_design #code_generation

Мой путь к быстрой и понятной архитектуре, или зачем я выбросил агрегаты из DDD?

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

https://habr.com/ru/articles/876742/

#ddd #domaindriven_design #domain_model #repository #use_case #c# #net #services #aggregate #entity

[Записки тимлида] Битрикс: от модулей к сервисам 3

Автор: Денис Закусило Приветствую всех неравнодушных! Это заключительная статья цикла о переходе от модульной архитектуры к сервисам. [Записки тимлида] Битрикс: от модулей к сервисам [Записки тимлида] Битрикс: от модулей к сервисам 2 Сегодня мы рассмотрим организацию структуры frontend стороны приложения.

https://habr.com/ru/articles/874078/

#bitrix24 #архитектура #javascript #domaindriven_design

DDD против реальности: распространённые ловушки и их решение в NestJS

Сложно внедрить DDD в NestJS, не запутавшись в абстракциях? В статье рассмотрены частые ошибки - от комбайна в контроллерах до формальных Value Objects. Разбираем, как выделять слои (Domain, Application, Infrastructure, Interface), правильно использовать Entities и репозитории и создавать поддерживаемую архитектуру.

https://habr.com/ru/articles/871494/

#nestjs #domaindriven_design #ddd #javascript #typescript #backendразработка #архитектура_приложений #rest_api #разработка_по #программирование

Тактические паттерны DDD

В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.

https://habr.com/ru/articles/854140/

#ddd #domaindriven_design #domain_driven #bounded_context #subdomain #active_record #domain_model #event_storming #DDD_Trilemma #typescript

Тактические паттерны DDD

В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.

https://habr.com/ru/articles/854140/

#ddd #domaindriven_design #domain_driven #bounded_context #subdomain #active_record #domain_model #event_storming #DDD_Trilemma #typescript

Тактические паттерны DDD

В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.

https://habr.com/ru/articles/854140/

#ddd #domaindriven_design #domain_driven #bounded_context #subdomain #active_record #domain_model #event_storming #DDD_Trilemma #typescript

Тактические паттерны DDD

В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.

https://habr.com/ru/articles/854140/

#ddd #domaindriven_design #domain_driven #bounded_context #subdomain #active_record #domain_model #event_storming #DDD_Trilemma #typescript

Предметно-ориентированное проектирование (DDD) и математическое моделирование

В статье будут проведены аналогии между предметно-ориентированным проектированием и математическим моделированием С математическим моделированием школьники знакомятся в 7 классе общеобразовательной школы. Грубо говоря, это перевод задачи из неформального человеческого языка на язык математики для последующего её решения.

https://habr.com/ru/articles/815497/

#DDD #domaindriven_design #math #математическое_моделирование #предметная_область

Пиррова победа Domain-Driven Design

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД. DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справится (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти , оказались неспособны гарантировать корректность данных в БД . А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД .

https://habr.com/ru/articles/800385/

#DDD #DomainDriven_Design #eventual_consistency #aggregate #saga #агрегат #сага

Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя

Слой Application - это не только про оркестрацию, но еще немного про бизнес-логику. Следует это простить и принять внутри себя. А иначе попытки продвинуться дальше в написании кода съедят программиста-перфекциониста живьем. Можно долго искать решения, читать различные комментарии и книги про разделение бизнес-логики от приложения. И все равно ваша конкретная ситуация будет казаться вам уникальной, как будто ничего нельзя сделать либо надо снова переписывать Domain слой, дабы ни одно зернышко бизнес-логики не выпало за его пределы. А можно просто закрыть глаза на некоторые моменты, забыть об идеале и спать спокойно, рассчитывая, что все чудесным образом само разрулится.

https://habr.com/ru/articles/797425/

#чистая_архитектура #domaindriven_design #принципы_проектирования

Стратегические паттерны DDD

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

https://habr.com/ru/articles/787460/

#ddd #domaindriven_design #domain_driven #bounded_context #ubiquitous_language #subdomain #domain #patterns #ddd_дизайн #domain_driven_architecture

Стратегические паттерны DDD

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

https://habr.com/ru/articles/787460/

#ddd #domaindriven_design #domain_driven #bounded_context #ubiquitous_language #subdomain #domain #patterns #ddd_дизайн #domain_driven_architecture