Rails is optimised for the first weeks of development. At the later phases it's no longer the speed of adding new views and data that matters. It's often more about the different (and changing!) ways of using the data. The business logic gets more complicated. DDD has answers to those problems. Detecting the bounded contexts is the crucial skill. Choose which parts of the app leave as CRUD and which could go into more of the tactical DDD.

1. From
Rails legacy
to
DDD
@andrzejkrzywda
Arkency

2. Agenda
• What is legacy
• Why and when Rails becomes legacy
• What is DDD
• Why it’s worth learning
• How to gradually go DDD - lessons learnt

3. Andrzej Krzywda
• 11 years with Rails
• running Arkency (Ruby agency)
• writing Ruby-related books
• RailsRefactoring.com
• blogging
• teaching Rails at University of Wroclaw (for the last 5 years)
• organising wroc_love.rb
• DRUG meetups in Wrocław

4. Andrzej Krzywda
• reviewed hundreds of Rails apps
• helped several Rails teams
• dealing with bigger Rails apps

5. What is legacy code?

6. Legacy
• Frameworks
• monolithic
• no architecture
• no tests

7. • “code written yesterday”
• “code written by someone else”
• “not my code”
• “not in my favourite architecture”

8. How do Rails apps
become legacy?

9. Rails is optimised for the
first weeks of
development

10. Bringing us joy and
speed

11. Optimised for adding
new forms/tables/
columns

12. Not optimised for
complex business logic

13. Refunding a ticket

14. What are the
symptoms?

15. • slow tests
• the test setup is long and complicated
• critical bugs more often
• slower development progress
• conflicts in the team, related to the code
• complicated codebase
• infinite API

16. DDD
Domain-Driven Design

17. DDD aims to help with
complex business logic

18. Most popular in .NET and
Java, but also strong in
the PHP community

19. Why is DDD not popular
in the Rails community?

20. Mostly due to our
Java-hate DNA

21. Why it’s worth learning
DDD?

22. • New techniques
• new tools
• Solutions to complicated business
logic
• solutions in non-Ruby worlds
• shared language with other
programmers
• microservices!

23. How to start?

24. Service objects are
the gateway drug

25. Strategic vs Tactical
DDD

26. Tactical DDD
• entity
• value objects
• aggregate
• domain event
• services
• repositories
• factory

27. 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)

28. • URL
• Rails action
• App service
• Domain service
• Repo
• ActiveRecord
• Database

29. One app service can call
multiple domain services

30. UpdateCustomer
==
MoveToNewAddress
ChangeEmail
IntroduceNewContactPerson
In one of our projects one request was about 15 domain services
“Update” is always hiding a lot

31. application
vs
domain

32. Strategic DDD
• bounded contexts
• context map

33. Warning: next slide is
almost like UML

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

35. Software House
management tool

36. optionally as microservices
partially available
different persistence
data duplication
Context Map
HR Project Management Finances
Invoicing
CRUD
DDD-lite
external SaaS
Communication
developer
project
client
DDD-lite

37. bounded contexts as
namespaces in Ruby

38. How to get there from
legacy?
BTW, There’s no such thing as the ultimate DDD codebase

39. Draw the Context Map
aka what are the boxes in your application
aka you have more apps
They are potential microservices

40. Decide which contexts are
CRUD and which ones
need more logic (DDD-lite)
the ones with CRUD ideally need to publish events anyway

41. Bounded contexts
• Inventory
• Invoicing
• Ordering
• Finances
• Forum

42. Ongoing process
No time for 2-months rewrites

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

44. Escape from the
CRUD verbs
Talk more to the business people

45. decrease
Convention over Configuration

46. Test coverage
#noregressions
when you’re a client you don’t like them too

47. Line coverage*
is
a joke
*rcov, simplecov

48. 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/

49. You want to try mutant
(today)

50. mutant
==
testing your tests
==
refactoring with confidence

51. 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/

52. Escape from the
framework ASAP
http://blog.arkency.com/2015/03/extract-a-service-object-in-any-framework/
Call application services from the framework
let Rails deal only with HTTP

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

54. Wrap your legacy
contexts with the
application services layer

55. Use events to
communicate between
bounded contexts
rails_event_store
https://github.com/arkency/rails_event_store

56. Sync may be safer
than async

57. Separate reads/writes
at the services layer
CQRS

58. Eliminate querying
from BC to another
Push the data!

59. Keep the Bounded Contexts
in-sync by publishing all the
important events

60. Easier testing when no
dependency on other
system

61. Read models
Denormalized data

62. When in doubt, think
in aggregates

63. Roles in DDD
http://andrzejonsoftware.blogspot.com/2015/09/dci-ddd-and-concept-of-roles.html

64. Event sourcing
build your aggregates from events
audit log for free

65. Distributed
transactions are tricky

66. Easier setup of the
project when it’s a smaller
piece
Useful when you’re maintaining many projects and need to bugfix them from time to time

67. Legacy -> DDD books
• red book, Vaughn Vernon
• Implementing DDD
• blue book, Eric Evans
• Refactoring, Fowler
• Legacy code, Feathers

68. THANKS!