What is Domain Driven Design (DDD) really about? How might Command Query Responsibility Segregation (CQRS) help us to build better software? Far from being esoteric concepts, they can be harnessed by everyday developers to create long-lasting, flexible solutions.

DDD and CQRS are gaining in popularity because they attack genuine challenges in software development. This course balances explaining important underlying theory with both design- and code-focused exercises, giving participants both understanding and new practical development skills.

Rather than teaching a framework, the course teaches a factoring and some ways to implement it, highlighting the key pitfalls to avoid along the way. During the course, a small application will gradually be built up from scratch. The course also includes coverage of testing, how to apply the insights from the course to existing systems and how to scale out a system developed using CQRS. Read more about CQRS and DDD on the CQRS FAQ

About the instructor Carl has extensive experience in software development and software architecture, both in active use, blogging, and teaching. He uses a variety of programming languages daily. Carl has worked in the software industry for the last 15 years. His experience spans over a wide range of paradigms and platforms, and he has developed everything from custom web site design and bioinformatics toolkits to grammar engines and compilers. His specialty is to make systems coordinate and systematize large amounts of heterogeneous data - or, more casual, "bringing order out of chaos." He also likes to heal major systems that are in need of an architect.

Day 1

The Challenge of "Database Driven" Software Development

Types of complexity

Scaling and consistency

Testing

Integration

Introduction to Domain Driven Design

Domains and Domain Models

Ubiquitous Language

Exercise on building a domain model

Bounded Contexts

Why boundaries matter

Context Maps

Decomposition in the domain

Composition in the UI

Exercises on boundary hunting

Commands, Queries and Events

Normalization and denormalization

Write models and read models

Events as the write-side/read-side

link

Eventual consistency and its

consequences

Designing commands

Designing queries

Exercise on command and query design

Message Busses

Messages as decoupling

Publish/Subscribe

Send vs. Publish

Building a simple message bus

Exercise on message bus implementation

Write Side Architecture

Command handlers

State sourcing vs. event sourcing

Introduction to aggregates

Building up aggregates from past events

Transactional safety

Exercise on command handlers and aggregates

Day 2

BDD Style Testing

Introduction to BDD

Commands, Events and BDD

Building a simple test framework

Exercise on BDD

Event Stores

Existing options

Building an event store on top of an RDBMS

Implementing a repository using an event store

Advantages of freeing aggregate representation from persistence

Optimizations using snapshots

Exercise on building an event store

Advanced Aggregate Design

Finding aggregate boundaries

Coping with relationships

Exercise on aggregate design

Building Read Sides

Overall approach

Relational DB read sides

NoSQL read sides

Other options

Re-building and introducing new read sides

Exercise on building read sides

Day 3

Sagas

What is a saga?

Different types of saga

Handling saga state

Building a simple saga framework

Exercise on sagas

Evolving a System

Refining domain models

Handling changes to commands

Event versioning

Handling event upgrade

Exercise on event upgrading

CQRS, DDD and Existing Codebases

Introducing bounded contexts to existing systems

Separating commands and queries

Migrating towards event sourcing

Scaling out

Using the read/write separation to scale

Scaling write sides by bounded context and by aggregate

Scaling within an aggregate

Message distribution and reliability

Message queues and ESBs

Other Opportunities

Parallel development and outsourcing

Recreating previous states for debugging

Forkunnskaper

A good working knowledge of the Java language, including classes, interfaces and generics. Some basic experience with JUnit is beneficial, but not essential