Ddd

Translation boundary protecting a bounded context's model from upstream language corruption; structure (FACADE+ADAPTER); ACL vs Conformist vs Open-Host Service; migration use with Strangler Fig

DDD strategic design: subdomain taxonomy (core/generic/supporting), bounded context definition, subdomains vs bounded contexts, physical/ownership boundaries, sizing heuristic (start wide), subdomain type evolution (all 6 transitions), growth management; Evans' originating treatment: Continuous Integration within context, false cognates vs duplicate concepts, context sizing trade-offs

Build vs buy vs open-source decision framework; subdomain type as the primary analytical tool (core → build, generic → buy/adopt, supporting → build simple); hidden costs of buying; platform team as internal build-once option; sourcing reversals as subdomain types evolve

*Building Event-Driven Microservices* — Adam Bellemare

Four-pattern spectrum: transaction script, active record, domain model, event-sourced domain model; subdomain-to-pattern mapping; transaction script failure modes; full tactical decision tree (pattern→architecture→testing strategy); migration paths between patterns

Six bounded context integration patterns grouped by team collaboration type; context map notation; model translation: stateless proxy (sync/async) and stateful aggregation (stream processing, BFF); private vs public events; Evans' originating eight-pattern taxonomy (Shared Kernel, Customer/Supplier, Conformist, ACL, Separate Ways, OHS, Published Language, CI) and transformation recipes

strategic distillation: CORE DOMAIN identification, generic subdomains, domain vision statement, highlighted core, cohesive mechanisms, segregated core, abstract core; escalation of distillation techniques

DDD tactical pattern for core subdomain business logic: value objects (immutable, identified by values), entities, aggregates (consistency boundary, one-per-transaction rule, aggregate root, OCC), domain events, domain services; Evans elaborations on associations, entity identity, context-dependent entity/VO classification, service partitioning, modules as model elements

*Domain-Driven Design* — Eric Evans

CDC, event sourcing, CQRS, immutability, write/read path, correctness without coordination; DDD: CQRS sync/async projections, architectural slices, event-sourced domain model four-step cycle; Fowler's four-way event taxonomy (notification/state-transfer/event-sourcing/CQRS)

Broker vs mediator topologies; DDD: three event types (notification, ECST, domain event); private vs public events; distributed big ball of mud anti-pattern; data liberation

Low-tech collaborative workshop; 10-step process (domain events, commands, policies, aggregates, bounded context candidates); when to use; two-phase facilitation; remote considerations; Rosa: Big Picture EventStorming for domain boundary/KPI mapping + KPI Value Tree; Process Modeling EventStorming for operational value stream analysis

organising principle for entire system; four patterns: System Metaphor, Responsibility Layers (Potential/Operations/Decision Support/Policy/Commitment), Knowledge Level, Pluggable Component Framework; Evolving Order; six essentials for strategic design

*Learning Domain-Driven Design* — Vlad Khononov

Evans' binding principle: one model for analysis and design; code is the model's expression; hands-on modellers; bones-showing; requires layered architecture for domain isolation; breakthroughs: non-linear returns, cascade of insights, Share Pie story

*Monolith to Microservices* — Sam Newman

O/R mapping architectural patterns (Table Data Gateway, Row Data Gateway, Active Record, Data Mapper); behavioural patterns (Unit of Work, Identity Map, Lazy Load); structural mapping; inheritance strategies (Single/Class/Concrete Table Inheritance)

Hexagonal/onion/clean architecture; DIP-inverted dependencies; business logic at centre; DDD fit: domain model and event-sourced domain model; architectural slices principle

Evans' REPOSITORY pattern: in-memory collection illusion over aggregate roots; hides persistence technology; only for roots needing direct access; transaction control left to client; factory/repository complementarity

*Software Architecture Metrics* — Ciceri et al.

predicate VALUE OBJECT for expressing domain rules: three uses (validation, selection/querying, building to order); composite Specification with AND/OR/NOT; subsumption; integrates with REPOSITORY via selectSatisfying()

Evans' six patterns for design that is easy to work with and extend: Intention-Revealing Interfaces, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations; declarative style as outcome

Technical (layered) vs domain (bounded context) top-level component design

DDD cornerstone practice: shared business language eliminating translation chains; must pervade the code; modeling out loud; documents must track UL or be archived; UML limitations; explanatory models as separate teaching aids