Scaling Domain Driven Design Greg Young IMIS
Presentation Is Is Not Discussion of DDD A DDD Tutorial being used in a large A Scalability Tutorial scale system Discussion of concepts that can be applied to other domains to solve common infrastructure issues
Context
IMIS Algorithmic Trading Regression Analysis Data Warehousing
Incoming Data • NT TSX / V • RIM • NT • EBAY NYSE • RIMM Nasdaq • CSCO
Challenges Large Amounts of Complex Business Logic Large Amounts of Historical Data Large Amounts of Real-Time Data Nearly all Real-Time Data is Stateful Extremely Low Latency (< 100 ms)
DDD & Performant Systems
DDD Scalability
Bounded Contexts Language Specialization Knowledge Hiding Team Partitioning Scalability??
Context Mapping Anti- Bounded Core Corruption Context Domain Layer
Many Bounded Contexts do not need real time data…
First Attempt Remote Domain Facade Async Analysis
Analysis Pros Cons Easily Scalable Fractured Domain/ Duplicated Logic Simplicity Wrong Language “ Retrofitability ” Too Much Information
If things seem hard, there is something wrong with the model…
Are state changes domain concepts?
Changes are First Class Citizens Customer CustomerAddressChangedMessage GetStateChanges()
Benefits Explicit! Testing Auditing Optimism
Annoyances Creating all of the messages (especially creates) Not easily applied to an existing domain
Reversed Anti- Core Bounded Corruption Domain Context Layer
How to send the state changes? Pipeline Pub/Sub Only a All or most of fraction of the data is data is needed needed Many Smaller Reporting Systems
Reporting Async Pipeline Reporting Domain Infrastructure
Warm/Hot Replication Async Pipeline Mirrorrer Domain
Load Balancing w/ Optimistic Locking Mirrorrer Domain
Striping (Partitioning) Locator Async Pipeline Striper Domain
Summary
Summary Bounded Contexts are Also for Scalability Most Context Mapping Need not be Synchronous State Changes are First Class Citizens
Questions
Recommend
More recommend
