From legacy to DDD

@andrzejkrzywda Arkency

What is legacy code?

Legacy

• Frameworks

• monolithic

• no architecture

• no tests

DDD

Strategic vs Tactical DDD

Tactical DDD• entity

• value objects

• aggregate

• domain event

• services

• repositories

• factory

DDD-lite• app service

• calls 1 or more domain services

• domain service

• takes repo as input

• load aggregate from the repo

• do sth cool

• may use some value objects

• may trigger some domain events

• save aggregate (repo)

• URL

• Rails action

• App service

• Domain service

• Repo

• ActiveRecord

• Database

One app service can call multiple domain services

UpdateCustomer ==

MoveToNewAddress ChangeEmail

IntroduceNewContactPerson

In one of our projects one request was about 15 domain services

“Update” is always hiding a lot

Strategic DDD

• bounded contexts

• context map

http://martinfowler.com/bliki/BoundedContext.html

Software House management tool

optionally as microservices partially available

different persistencedata duplication

Context MapHR Project Management Finances

Invoicing

CRUD

DDD-lite

external SaaS

Communication

developer project client

DDD-lite

How to get there from legacy?

BTW, There’s no such thing as the ultimate DDD codebase

Draw the Context Mapaka what are the boxes in your application

aka you have more appsThey are potential microservices

Decide which contexts are CRUD and which ones

need more logic (DDD-lite)the ones with CRUD ideally need to publish events anyway

Ongoing processNo time for 2-months rewrites

Peopleware the human factor

http://andrzejonsoftware.blogspot.com/2014/01/refactoring-human-factor.html

Escape from the CRUD verbsTalk more to the business people

Test coverage

#noregressions

when you’re a client you don’t like them too

Line coverage is

a joke

Mutation testing is the real test coverage!

http://blog.arkency.com/2015/04/why-i-want-to-introduce-mutation-testing-to-the-rails-event-store-gem/

http://blog.arkency.com/2015/06/how-good-are-your-ruby-tests-testing-your-tests-with-mutant/

You want to try mutant

(today)

https://github.com/mbj/mutant

mutant ==

testing your tests ==

refactoring with confidence

Test units, not classes!http://andrzejonsoftware.blogspot.com/2015/02/tdding-unit-not-class.html

http://andrzejonsoftware.blogspot.com/2014/04/tdd-and-rails-what-makes-good-unit.html

http://blog.arkency.com/2014/09/unit-tests-vs-class-tests/

Escape from the framework ASAP

http://blog.arkency.com/2015/03/extract-a-service-object-in-any-framework/

Call application services from the framework

Active Record doesn’t make your code happy

AR is not DDD-lite-friendlyData Mapper is better here

ActiveRecord is a short-term loan

are you able to pay the debt?what is your credit history?

Don’t just pass the params/hash everywherehttp://andrzejonsoftware.blogspot.com/2011/12/args-opts-params.html

Wrap your legacy contexts with the

application services layer

Use events to communicate between

bounded contextshttps://github.com/arkency/rails_event_store

https://github.com/arkency/ruby_event_store

Sync may be safer than async

Separate reads/writes at the services layer

CQRS

Eliminate querying from BC to another

Push the data!

Keep the Bounded Contexts in-sync by publishing all the

important events

Easier testing when no dependency on other

system

Read modelsDenormalized data

Treat your frontend as a separate Bounded

Context

When in doubt, think in aggregates

Event sourcingbuild your aggregates from events

audit log for free(no, it’s not slow, but thanks for asking)

Distributed transactions are tricky

Easier setup of the project when it’s a smaller

pieceUseful when you’re maintaining many projects and need to bugfix them from time to time

Legacy -> DDD books• red book, Vaughn Vernon

• Implementing DDD

• blue book, Eric Evans

• Refactoring, Fowler

• Legacy code, Feathers

• Fearless Refactoring: Rails Controllers

THANKS!andrzej@arkency.com