DDD and Beyond … on Rails!!

Why Rails?

• Ruby is awesome!• Vibrant community & ecosystem• CoC - less boilerplate code• Supports rapid development• Asset pipeline• Built-in ORM – ActiveRecord• And more …

Why DDD?• Powerful practices & patterns for tackling complex problems

– Both tactical and strategic• Align business & technology

– Zero translations (Ubiquitous Language)– Domain experts contribute to software design– Code becomes a living description of the business

• Increased clarity and understanding– Collaboration that results in well understood models

• Strategic development– Prioritize resources & investment toward more complex or differentiating

areas of the business• Organized architecture

– Align physical systems with distinct areas of the business

DDD on Rails

Rails• Ruby is awesome!• Vibrant community• Less boilerplate• Rapid development• Asset pipeline• ActiveRecord

DDD• Tackle complex domains• Align business & technology• Clarity & understanding• Strategic development• Organized Architecture

* ActiveRecord is a DDD antipattern ….

DDD: Strategic Patterns

SubdomainsUbiquitous Language

Bounded Context

• Separate areas of the business• Ideally one Domain Model per Subdomain

• Language used & understood by all stakeholders in a project • Used to express a Domain Model

• Sets the context for terms in a Ubiquitous Language• Ideally one Bounded Context per Subdomain

Conference Management

Subdomains

Ubiquitous Language

• Program Mgmt. Context– Organizers create Conferences– Organizers call for Proposals– Candidates submit Proposals– Once received, Reviewers rate Proposals– Organizers choose Proposals for Session topics

• Access Control Context– Public Users register to create an Account– Accounts are assigned to one or more Roles– Users sign in to begin an authenticated Session

User Story:As a candidateI would like to submit a proposal to a conferenceSo that it may be available for review

Ubiquitous Language

Isolating Contexts

Gem, Engine, App

Gem, Engine, App

Anticorruption Layer

DDD: Tactical Patterns

• Entity• Aggregate• Repository• Value Object• Domain Event• Domain Service

* Building blocks of a Domain Model

ActiveRecord – Schema First

DDD – Model First

ActiveRecord

DDD Entity

Organizer creates a conference.

ActiveRecord

DDD Entity

Organizer calls for proposals.

ActiveRecord

DDD Entity

Candidate creates and submits a proposal.

ActiveRecord

Proposals can only be received once the organizer has called for proposals.

DDD Entity

Proposals can only be received once the organizer has called for proposals.

ActiveRecord vs DDD Entity

ActiveRecord• Shaped by DB schema• CRUD semantics baked in• No Encapsulation• Multiple responsibilities

– Data access– Business logic– REST resource/view data

DDD Entity• Shaped by UL• Blank canvas to express UL• Enforces invariants• Single responsibility

– Encapsulate business logic

Repositories

• Collection semantics for an Aggregate Root– add(conference), find_by(id) etc.

• Modify one Aggregate per transaction *– Consistency boundary– Watch out for false invariants

• Easily implemented with NoSQL solutions– Object/Document/Key-values etc.

Event Sourcing

• Raise explicit event for every state change• Persist serialized events to an event store

• To retrieve persisted entity– Deserialize events and replay– Conference.allocate.replay(events)

Event Name Source Id Event Args

conference_created 7 { id: 12, name: “Test Conf” }

conference_scheduled 7 { id: 12, date: “2013-31-01”}

proposal_received 7 { id: 12, title: “Test Prop …

Event Sourcing & CQRS

Client

Application

Domain Model

Commands Queries

Query Store

Application

Read-only

AsyncHandlers

DB

Events

More Information

• A great DDD Introhttp://www.infoq.com/minibooks/domain-driven-design-quickly

• More on CQRShttp://cqrs.wordpress.com/2010/09/08/welcome-to-cqrs-info/

• My Open Source Projecthttps://github.com/domaindrivendev/puree