Domain Driven Rails

@skwp @reverbdotcom #wcr14

Yan PritzkerCTO, Reverb.com

@skwp @reverbdotcom

Domain Driven Rails

https://speakerdeck.com/skwp

http://Reverb.com



Are you happy with the SIZE and COMPLEXITY

of your models?


Are you happy with the SCALABILITY of your team?


Are you happy with the ADAPTABILITY

of your business?


What are you building?


Rails is a detail!"

Decouple all things"

Is the code better?"

Keep it Railsy"


Somewhere in between

Simple CRUD"Apps"

Complex Enterprise

Logic"


I want to discover relevant compromises

rather than defend ideals


Over 115

Model Classes


Over 1000 Total

Classes


Not great, but we have only three chubby models


Are monoliths bad for business?


Quick IterationsLow Operational

ComplexityRefactoring

Monolith

ServiceService

Service Service

Service

Early 2013 - Startup / Proof of Concept

Monolith

ServiceService

Service Service

Service

2014 - Growth Phase


http://martinfowler.com/articles/distributed-objects-microservices.html

“I'm wary of distribution and my default inclination is to prefer

a monolithic design”

“While small microservices are certainly simpler to reason about, I worry that this pushes complexity into the

interconnections between services”

“Refactoring becomes much harder when you have to do it across remote boundaries.”


Quick IterationsLow Operational

ComplexityMay lead to a BBOM


Maintainable Monoliths

Can Be Achieved


Product 400 LOC

~150 LOC non-ActiveRecord Churn: 49 changes this year"

Order 333 LOC

~200 LOC non-ActiveRecord Churn: 36 changes this year

User 338 LOC

~200 LOC non-ActiveRecord Churn: 29 changes this year

CHURN

Product

OrderUser


Commonly used classes are hard

to refactor


Stop modifying

code!(Open/Closed Principle)


Don’t put different rates

of change together"

Kent Beck - Smalltalk Best Practice Patterns(see also: Single Responsibility Principle)


Don’t put different rates

of change together"

Kent Beck - Smalltalk Best Practice Patterns

Data Model

Business Logic


Separate what the system is "

from what the system does"

James Copelien & Trygve Reenskaug(Data, Context, Interaction)


Where does business logic go?


Controller

2005

ActiveRecord

Mailers

Services

User


Console?"Rake task?"

Background jobs?"API layer?"Testing?

What about…


Order

Fat models?


OrderRefund


OrderRefund

Ship


OrderRefund

ShipCheck Fraud Risk


“Active Record is a good choice for domain logic that isn't too

complex, such as creates, reads, updates, and deletes”

Martin Fowler


If Controller and Model are all you have then

one has to be skinny and one has to be fat


Domain Layerskinny framework,

healthy business logic,"no fat anywhere

http://joncairns.com/2013/04/fat-model-skinny-controller-is-a-load-of-rubbish/

Model

Controller

View

The Rails WayThe

WayActiveRecord

Use Cases

Grape API

ControllersCron

Redis

Rake

HTTP Services

Workers

REntities

Roles

DB

ListenersEvents


app/reverbfor app specific


lib/reverbfor Open Source / Generic


Reverb::Namespace to avoid collisions with gems


This is amarketplace!

http://blog.8thlight.com/uncle-

bob/2011/09/30/Screaming-

Architecture.html


http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html


see also Hexagonal, Ports & Adapters, DCI


Clean Enough

Architecture"


Choosing the right fight


http://blog.8thlight.com/mike-ebert/2013/03/23/the-repository-pattern.html


http://blog.8thlight.com/mike-ebert/2013/03/23/the-repository-pattern.html

(but you should still read this)


User.where(…)User.activeUser.find(1)

This is easy to replace with something other than AR. Repository not required.

Don’t leak SQL outside of AR


Domain Logic in ActiveRecord and

Controllers leads to Churn


Use CasesReify complex business logic

into classes


This is not"Rails


Explicitly Require Dependency

http://myronmars.to/n/dev-blog/2012/12/5-reasons-to-avoid-bundler-require

Invoke It


Code Reuse!

Thin Shell


Stubby

Happy Path


Testing conditionals and side effects has nothing to do with Rails


NamingThe hardest problem in computer science


OrderService


OrderService

NounService Grows Unbounded


Use verbs to narrow your scope


Order


Order

ShipOrder


Order

ShipOrder Cancel Order


Order


RefundOrder


Order


RefundOrder

Does notgrow over time



RefundOrder

Don’t change"once you write them


Ubiquitous Language


What is this?


RolesAdd methods to objects on demand

in the context of a Use Case


Decorator


We added these methods


Methods related to each"other but loosely related"

to the parent concept"and used only in a few"

Use Cases


EventsAdd behavior with listeners

without modifying code


Order

ActiveRecord Callbacks

Send Email


Order


Send Email

Call External Service


Order


Send Email

Call External Service

ConditionalCallbacks


AR callbacks become more complex as the

system supports more use cases


Different use cases may trigger different events

even when working with the same model

Instead


Add another listener to add behavior The core class doesn’t change


Global listeners for cross-cutting concerns without littering code

Wisper::GlobalListeners.add(Reverb::Listeners::AnalyticsListener.new)"


Controller is a listener too


Policy ObjectsReify complex business rules

into objects


Likely to change

Unlikely to change


refactored for readability


Injectable, but has a default

Simple code, only need to test one pathfor the imperative side effect"

(sending an email)


Distillation Time


Language of codebase reflects language of business


Separate behaviors (what the system does) from models (what the system is)


Rates of Change


Is this all Unicorns and Rainbows?


Sprawl?"Onboarding?"

Naming?"Documentation?"


http://blog.mattwynne.net/category/hexagonal-rails/

http://clean-ruby.com/

Resourceshttp://confreaks.com/videos/759-rubymidwest2011-keynote-

architecture-the-lost-years

http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html

http://www.artima.com/articles/dci_vision.html

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html




We Are Hiring Always"

jobs.reverb.com

Ruby, ElasticSearch, DevOps, Designers, Android, and more!

[email protected]

http://jobs.reverb.com

mailto:[email protected]

Domain Driven Rails

Technology

Transcript of Domain Driven Rails