What is event-driven architecture and domain-driven design?

Domain-driven design (DDD) aligns software with the business: a shared *ubiquitous language*, bounded contexts that own their model and data, and aggregates that protect invariants inside one transaction boundary. Use it where the domain is genuinely complex.

Event-driven architecture has components publish facts (events) that others react to, decoupling producers from consumers.

• Pub/sub and streaming (queues, Kafka-style logs) for fan-out
• CQRS — separate write and read models when their needs diverge
• Event sourcing — store the sequence of events as the source of truth (powerful, but costly to operate)
• Sagas — coordinate multi-step business transactions across services with compensating actions instead of distributed locks

Trade-offs: eventual consistency, harder debugging and duplicate delivery. Use the transactional outbox and idempotent consumers, and adopt these patterns only where the problem demands them.