Domain Driven Design in the
Browser
Better Living through Software Modeling

The job of software is to solve
problems having to do with a
particular domain.

What’s a Domain?
A domain is an area of expertise.
It could be a industry field, like accounting, or a subject of
interest, like penguins.

Matchmaking
OkCupid

Social Networking
Facebook

Data Analysis
SumAll

Graphic Design
Photoshop

Research
EasyBib

Successful software starts
with a focus on the domain.

How do I “focus on the
domain?”

First, seek understanding
from domain experts.
They know more than you do.
experts are sometimes known as “business stakeholders” or “product

Who is an expert in my domain?

Matchmaking
These people (shadchanim)

Social Networking
This guy.

Data Analysis
George Box (a famous statistician)

Graphic Design
David Carson

Research
Allison “I Know a Lot About Research” Cloyd

Next, create a model of the domain
that you can use in your software.

What is a model?

A blueprint of the domain that
exists in the mind of the developer.

0100101111010101
0010010101010101
0010100101010101
0010101010100010
0100101010101010
1000100100100000
1110101010101000
1010111011010101
1010100100100011
0100000011101010
1010100000101010
1001101001010111
0100101011010101
0101010101010101
0101000111000111
1001001100101010
1010001010101011
1011010101001010
1001010101000000
study research
hypothesis control
group experiment
conjecture theorem
law theory evidence
abstract introduction
premise discussion
findings conclusion
footnotes citations
reference explanation
methodology thesis
support database
explication essay
news opinion book
source review peer
editor commentary
empirical history case

Some common misconceptions
about the model

The model is not
source code.
You have code that reflects the model,
and it contains words that come from the
model.
But code is just an implementation of
the model. The model exists in the mind
of the developer.

The model is not
the database.
Some of the data associated with the
model is in the database. And the
database schema is another
implementation of the model.
But the model encompasses all of the
domain logic AND data, and it exists in
the mind of the developer.

The model is not a
diagram
A diagram is just a picture of the model.
The model itself exists in the mind of
the developer.

Some perks of using a model

Ubiquitous Language

Scalably Handling Complexity

Manageable Knowledge Sharing

How do I translate the domain
expert’s knowledge into a model?

1.Verbal Communication
2.Diagramming
3.Use Cases

The Stuff that Models are
Made Of

Entities
Objects with a unique, persistent identity
We track this identity using a key or a combination of
properties

Some examples of entities:
Entity Type Identifier
• Person/User Email
• Bank Account Account #
• Shipping Route Id
• Book ISBN

Value Objects
Second class objects with no identity, just value
Value objects are always properties of entities
They’re immutable: they’re usually only changed by
replacement

Name

Factories
The job of factories is to make entities

Printer

Services
Services are the verbs of an application.
Their state doesn’t matter so much.
They have a job to do.

CitationService

CitationService.formatBook(string title, CiteStyle style)
1. Call the WorldCat API to get publication info about the book.
2. Pass the WorldCat response object to BookFactory.fromWorldCat()
3. For analytics, pass the Book object to BookRepository and call
BookRepository.save().
4. Using the name of the CiteStyle, pass the Book to a ViewFactory
for formatting and return the View.

Repositories
The persistence layer
Buckets for data

Some Benefits of Repositories
• A repository is an interface, so you can read and write persistent
data without knowing where it’s going. You can say repository.read()
and it might read from a REST API, web sockets, local storage, or
even memory.
• That’s why a repository is called a Persistence Abstraction Layer.

Layered Architecture

Application
Domain
Utilities

Application Layer
• Views
• RequestControllers (traditionally called “Controllers”)
• ViewModels
• Assets - CSS, JavaScript, images
• UI Details - UIControllers, Data Bindings
• Any other application-specific logic (console applications, cron tasks,
etc.)

Domain Layer
• Entities
• Factories
• Services
• Repositories
• Any other domain-specific logic that’s reusable across applications

Utilities Layer
• Libraries - Math Utilities, CSV Parsers, DOM Selection Utilities, Data
Structure Helpers, ORM Tools
• Frameworks - Backbone, Symfony, Rails, Django
• Anything that’s reusable across domains

Some Rules for Layered Architecture

Information flows one way: up

References
Objects in one layer can refer to objects in any lower layer.
Objects in one layer can refer to objects in that same layer.
Objects in one layer CANNOT REFER TO OBJECTS IN A HIGHER LAYER.

Let’s Get Some Practice
For some more good reading, go to http://www.loewenbraeuzelt.de/wp-content/
uploads/DomainDrivenDesignQuicklyOnline.pdf
Or check out Eric Evans’ Book, Domain Driven Design

In This Presentation
• See the working app: cornellnotes.nodejitsu.com
• GraphJS: https://github.com/cameronprattedwards/graphjs
• entity-context: https://github.com/cameronprattedwards/entity-context
Contributors wanted!