DDD-rail your Monorail

The scene cuts to the offices of Delorean - the hottest time-transport startup in town (“it’s like Uber for time travel!”). Beneath the glitzy face of the fast-growing company, we find a defeated engineering team struggling with a large Rails monolith, complete with the battle scars of anemic domain models, spaghetti code, and cut corners. The team is shipping fewer features while battling increasing rates of unexpected regressions. The team wants to break up the monolith to combat complexity, but where do they begin? Join the team as they turn to three Domain-Driven Design (DDD) techniques to discover key domain insights and attempt to design their way out of the monolith mess into a well-defined, cleanly segregated, and service-oriented future. Will they succeed, or will the inexorable tides of time and entropy forever trap this team in the past?

Presentation: https://www.youtube.com/watch?v=TljmIXW2fwM

Don't forget to check out the companion sample app: https://github.com/andrewhao/delorean

Transcript

1. DDD-rail Your Monorail Breaking up the Rails monolith with domain driven design
2. Hi, I’m Andrew
4. Meet Delorean “It’s like Uber, for time travel!”
5. The situation
6. %
7. What happened?
8. In the beginning, there was an app.
9. The business decides… • Drivers deliver passengers from year A to year B. ⌛
13. The business decides… • Drivers deliver passengers from year A to year B. ⌛ • Passengers choose the type of Delorean service they want.
17. The business decides… • Drivers deliver passengers from year A to year B. ⌛ • Passengers choose the type of Delorean service they want. • Time travel carpools! 01
21. The business decides… • Drivers deliver passengers from year A to year B. ⌛ • Passengers choose the type of Delorean service they want. • Time travel carpools! 01 • DeloreanEATS: Customers order food, drivers pick up from time period and deliver to customer time period!
25. Hm.
27. Regressions
28. The Payments team regresses Trip while refactoring ServiceTier
29. The Restaurants team deploys a new pricing algorithm that regresses rideshare pricing
30. Responsibilities?
31. The Mobile team requests a new mobile login API, but which team should implement it?
32. Business won’t stop
33. Outsourced dev shop is rebuilding the marketing home page and needs a pricing API.
34. CEO wants to launch "Airbnb for time travel” feature in, let’s say, 2 months!
35. Does this sound familiar?
36. There are deeper insights to be had
37. What is DDD?
38. A set of techniques to arrive at a flexible design that cleanly maps to the business model
39. Strong, expressive domain models
40. There is no such thing as a One True Perfect model
41. Embrace the chaos
42. Domain-Driven Design: Eric Evans Implementing Domain- Driven Design: Vaughn Vernon
43. Let’s get designing!
44. Step 1: Visualize your domain models
45. Rails ERD https://github.com/voormedia/rails-erd
46. Ruby gem to generate UML diagrams from your ActiveRecord models
48. This helps you get the entire system into your mind.
49. Print it out! ✏
50. Step 2: Find your core- and sub-domains
51. Concept: Core Domain
52. What a business does
53. Transportation Core Domain
54. Concept: Subdomains
55. A supporting unit within the business
56. Rideshare Subdomain Food Delivery Subdomain Financial Transaction Subdomain Identity and Access Subdomain
57. Ridesharing Food Delivery Financial Transactions Identity/ Access
58. Step 3: Get the team talking in the same language
59. Concept: Ubiquitous Language
60. A defined language that is used consistently across business and technical contexts
61. Bring in the domain experts
62. A Driver picks up a Passenger
63. A Passenger requests a Pickup
64. An Owner drives a Vehicle
65. An Operator? drives a Vehicle
66. A User logs in and changes her Password
67. An Invoice is delivered to the Passenger
68. A Customer orders an item from a Menu, which is picked up and delivered by the Delivery Agent
69. Step 4: Make a glossary
70. Ridesharing • Passenger: “…” • Driver: “…” • Trip: “…” • Pickup: “…” • Vehicle: “…” • Vehicle Owner: “…”
71. Financial Transaction • Invoice: “…” • Order: “…” • Payment: “…” • Royalty: “…” • Salary: “…”
72. Identity and Access • User: “…” • Secure password: “…” • Role: “…”
73. Print ‘em out! ✏
74. Step 5: Draw out your software systems (bounded contexts)
75. Concept: Bounded Contexts
76. A software system that defines the applicability of a ubiquitous language
77. FoodDeliveryService TripRoutingEngine “menu” “trip” “restaurant” “plan” “delivery” “pickup” “customer date” “destination”
78. Software systems are natural boundaries for these linguistic terms
79. If a term leaks into a different software system/bounded context, you have a smell
80. Ridesharing Financial Transactions Identity/ Access Food Delivery DeloreanMonolith StripeAPI
81. DeloreanMonolith Ridesharing Financial Transactions Identity/ Access Stripe API Food Delivery
82. DeloreanMonolith Identity/ Access Food Delivery Driver Routing Service Fraud Detection Service (etc)
83. DeloreanMonolith Ridesharing Financial Transactions Identity/ Access Stripe API Food Delivery
84. Step 6: Now add directional dependencies
85. DeloreanMonolith Ridesharing Financial Transactions Identity/ Access Stripe API Food Delivery U D
86. DeloreanMonolith Identity/ Access Food Delivery Driver Routing Service Fraud Detection Service (etc) U U D U D U D
87. This helps you see dependencies between teams, where communication will be most important.
88. Context Map: A tool to visualize how your software systems relate to each other and the domain(s)
89. Our goal is to map our bounded contexts directly to our subdomains.
90. Ridesharing Financial Transactions Identity/ Access Stripe API Food Delivery
91. Show me the code!
92. Tactic 1: Get the names right
93. Adjust your class and method names to reflect the ubiquitous language
94. # old User.without_drivers # new Passenger.hailing_drivers # old order.calculate_cost # new order.calculate_billing_total
95. Tactic 2: Namespace and modulize your domains
96. Break Rails’ folder structure conventions
97. app/domains/financial app/domains/financial/inflation_adjustment.rb app/domains/financial/invoice.rb app/domains/food_delivery app/domains/food_delivery/menu.rb app/domains/food_delivery/menu_item.rb app/domains/food_delivery/menu_items_controller.rb app/domains/food_delivery/menus_controller.rb app/domains/identity app/domains/identity/user.rb app/domains/identity/users_controller.rb app/domains/rideshare app/domains/rideshare/driver.rb app/domains/rideshare/passenger.rb app/domains/rideshare/service_tier.rb
98. class Menu < ActiveRecord::Base belongs_to :restaurant end
99. module FoodDelivery class Menu < ActiveRecord::Base belongs_to :restaurant end end
100. class Trip < ActiveRecord::Base belongs_to :service_tier belongs_to :vehicle end
101. module Rideshare class Trip < ActiveRecord::Base belongs_to :service_tier belongs_to :vehicle end end
102. Domain code stays together
103. Tactic 3: Design with Aggregate Roots
104. Aggregate: A collection of domain objects that can be treated as a single unit
105. Use aggregates to model real-world entities that belong together
106. Aggregate Root: An entity at the “top” of the collection that can represent the whole
107. FoodDelivery aggregate root: Order
108. Food Delivery
109. A user adds a menu item to their cart
110. A User adds a MenuItem into their ShoppingCart
111. module Financial class ShoppingCart def order @order ||= FoodDelivery::Order.new end def amount @order.menu_items.sum(&:cost) + @order.menu_items.sum(&:tax_amount) end def add(item) order.menu_items << item end def remove(item) order.menu_items.delete(item); order.save end end end
112. module FoodDelivery class Order < ActiveRecord::Base belongs_to :user has_many :order_menu_items has_many :menu_items, through: :order_menu_items end end
113. module FoodDelivery class Order < ActiveRecord::Base belongs_to :user has_many :order_menu_items has_many :menu_items, through: :order_menu_items def total_cost item_cost + tax_cost end def item_cost menu_items.sum(&:cost) end def tax_cost menu_items.sum(&:tax_amount) end def add_item!(menu_item) menu_items << menu_item end def remove_item!(menu_item) menu_items.delete(menu_item); save end end end
114. module Financial class ShoppingCart def order @order ||= FoodDelivery::Order.new end def amount @order.total_cost end def add(item) order.add_item!(item) end def remove(item) order.remove_item!(item) end end end Calculation logic kept in FoodDelivery domain Implementation- agnostic
115. The root items of these aggregates are the only entities that external callers may fetch
116. Ridesharing Financial Transactions Identity/Access Food Delivery
117. Building good interfaces for a service oriented future!
118. Tactic 4: Break database joins between domains
119. `has_many`-itis!
120. module Rideshare class Trip < ActiveRecord::Base belongs_to :service_tier has_many :trip_pool_trips has_one :trip_pool, through: :trip_pool_trips belongs_to :driver, foreign_key: :driver_id, class_name: I belongs_to :passenger, foreign_key: :passenger_id, class_n belongs_to :vehicle belongs_to :order, class_name: FoodDelivery::Order has_one :payment end
121. These tend to happen in your God Objects
123. module Rideshare class Trip < ActiveRecord::Base belongs_to :service_tier has_many :trip_pool_trips has_one :trip_pool, through: :trip_pool_trips belongs_to :driver, foreign_key: :driver_id, class_name: I belongs_to :passenger, foreign_key: :passenger_id, class_n belongs_to :vehicle belongs_to :order, class_name: FoodDelivery::Order has_one :payment end
124. module Rideshare class Trip < ActiveRecord::Base # belongs_to :order, class_name: FoodDelivery::Order def order FoodDeliveryAdapter.new.order_from_trip(self) end end end
125. module Rideshare class FoodDeliveryAdapter def order_from_trip(trip) FoodDelivery::Order.find_by(trip_id: trip.id) end end end
126. Decoupling domains now will ease your architectural transitions later
127. You can do this all in small steps!
128. Toward a distributed architecture
129. Namespaced, Isolated Modules to Rails Engines
130. Component-Based Rails Engines (Stephan Hagemann)
131. Rails engines to a remote (micro-)service
132. Good architecture goes a very long way.
133. To recap
134. Drew things on a wall
135. Came up with a language
136. Moved code around
137. Team is on the same page
138. Big idea: Your software speaks the same language as your domain experts
139. Big idea: Bounded contexts are separators for linguistic drivers. Keep your language consistent in one and only one system
140. Big idea: Domain code should live together
141. Big idea: Adapters between domains enforce domain purity
142. Big idea: Incremental changes
143. Thanks! Sample code: https://github.com/andrewhao/delorean Slides: https://github.com/andrewhao/dddrail-talk Twitter @andrewhao Github @andrewhao 8