Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Built to Last: A domain-driven approach to beau...

Built to Last: A domain-driven approach to beautiful systems

Given at Railsconf 2017, April 27

Help! Despite following refactoring patterns by the book, your aging codebase is messier than ever. If only you had a key architectural insight to cut through the noise.

Today, we'll move beyond prescriptive recipes and learn how to run a Context Mapping exercise. This strategic design tool helps you discover domain-specific system boundaries, leading to highly-cohesive and loosely-coupled outcomes.

With code samples from real production code, we'll look at a domain-oriented approach to organizing code in a Rails codebase, applying incremental refactoring steps to build stable, lasting systems!

Andrew Hao

April 27, 2017
Tweet

More Decks by Andrew Hao

Other Decks in Programming

Transcript

  1. And it's a hot mess! We moved a teensy bit

    too fast: 1. Too many teams in one codebase
  2. And it's a hot mess! We moved a teensy bit

    too fast: 1. Too many teams in one codebase 2. Changing a feature changes multiple codebases
  3. And it's a hot mess! We moved a teensy bit

    too fast: 1. Too many teams in one codebase 2. Changing a feature changes multiple codebases 3. Concepts inconsistently named
  4. And it's a hot mess! We moved a teensy bit

    too fast: 1. Too many teams in one codebase 2. Changing a feature changes multiple codebases 3. Concepts inconsistently named 4. Ship, ship, ship! (No time to refactor)
  5. I've been thinking about beautiful systems In the language -

    syntax, form, expressiveness In the tooling - developer ergonomics
  6. I've been thinking about beautiful systems In the language -

    syntax, form, expressiveness In the tooling - developer ergonomics In the tests - test practices & coverage
  7. I've been thinking about beautiful systems In the language -

    syntax, form, expressiveness In the tooling - developer ergonomics In the tests - test practices & coverage In its longevity - whether it stands the test of time with changing business and product requirements
  8. Long-lasting systems Just large enough - knows its boundaries Highly

    cohesive and loosely coupled Precise semantics that fully express the business domain
  9. A blast from the past Information hiding D.L. Parnas -

    "On the Criteria to Be Used in Decomposing Systems into Modules"
  10. "We propose instead that one begins with a list of

    dif cult design decisions or design decisions which are likely to change. "Each module is then designed to hide such a decision from the others." (Emphasis added)
  11. From software program to the entire system Where are the

    dif cult design decisions in this company that are likely to change?
  12. From software program to the entire system Where are the

    dif cult design decisions in this company that are likely to change? Within the business groups that generate them!
  13. A peek into the life of our systems: Marketing wants

    us to generate 5000 promo codes Finance needs us to implement a new audit log
  14. A peek into the life of our systems: Marketing wants

    us to generate 5000 promo codes Finance needs us to implement a new audit log Product teams want us to launch new food delivery features.
  15. A peek into the life of our systems: Marketing wants

    us to generate 5000 promo codes Finance needs us to implement a new audit log Product teams want us to launch new food delivery features. Marketing wants us to invalidate 2000 of the 5000 codes
  16. A peek into the life of our systems: Marketing wants

    us to generate 5000 promo codes Finance needs us to implement a new audit log Product teams want us to launch new food delivery features. Marketing wants us to invalidate 2000 of the 5000 codes Finance needs us to add another attribute to the audit log
  17. A peek into the life of our systems: Marketing wants

    us to generate 5000 promo codes Finance needs us to implement a new audit log Product teams want us to launch new food delivery features. Marketing wants us to invalidate 2000 of the 5000 codes Finance needs us to add another attribute to the audit log Product teams want us to launch food delivery in a second market
  18. A peek into the life of our systems: Marketing wants

    us to generate 5000 promo codes Finance needs us to implement a new audit log Product teams want us to launch new food delivery features. Marketing wants us to invalidate 2000 of the 5000 codes Finance needs us to add another attribute to the audit log Product teams want us to launch food delivery in a second market (That sounds like change!)
  19. How do we get out of the world of the

    monolith? Microservices sound hard!
  20. How do we get out of the world of the

    monolith? Microservices sound hard! How much should I plan to extract?
  21. How do we get out of the world of the

    monolith? Microservices sound hard! How much should I plan to extract? What if I extract something that's too speci c? Too generic?
  22. How do we get out of the world of the

    monolith? Microservices sound hard! How much should I plan to extract? What if I extract something that's too speci c? Too generic? If only there were something to help me visualize what I need...
  23. Introducing Domain-Driven Design Published by Eric Evans in 2003 DDD

    is both a set of high-level strategic design activities and concrete software patterns
  24. Today: We will build a Context Map and use it

    to introduce DDD concepts We will learn some refactoring patterns we can use to shape our systems.
  25. De nition! Ubiquitous Language A Ubiquitous Language is a shared

    set of concepts, terms and de nitions between the business stakeholders and the technical staff. Use the language to drive the design of the system.
  26. Apply It! Develop a Glossary Get your business domain experts

    and technical staff together in a room and build a de nition list of the concepts and the actions in your domain.
  27. A sample glossary Driver: [Entity] A User providing driver services.

    S/he typically owns a Vehicle. Rider Passenger: [Entity] A User seeking a ride to a speci ed [time-traveling] location.
  28. A sample glossary Driver: [Entity] A User providing driver services.

    S/he typically owns a Vehicle. Rider Passenger: [Entity] A User seeking a ride to a speci ed [time-traveling] location. HailedDriver: [Event] A user has signaled their intent to seek out a ride.
  29. A sample glossary Driver: [Entity] A User providing driver services.

    S/he typically owns a Vehicle. Rider Passenger: [Entity] A User seeking a ride to a speci ed [time-traveling] location. HailedDriver: [Event] A user has signaled their intent to seek out a ride. ChargedCreditCard: [Event] A customer credit card has been charged for a transaction.
  30. Apply It! Rename concepts in code Listen to the language,

    and see if the wording ows. Renaming concepts in code is appropriate here!
  31. Apply It! Rename concepts in code Listen to the language,

    and see if the wording ows. Renaming concepts in code is appropriate here! user.request_trip ➡ passenger.hail_driver
  32. Apply It! Visualize Your System Let's generate an ERD diagram!

    I like to generate mine with a gem like railroady or rails-erd If you have multiple systems, do this for each system.
  33. De nition! Core domain The Core Domain is the thing

    that your business does that makes it unique.
  34. De nition! Core domain The Core Domain is the thing

    that your business does that makes it unique. Delorean Core Domain: Transportation
  35. De nition! Supporting domains A Supporting Domain (or Subdomain) are

    the areas of the business that play roles in making the Core Domain happen.
  36. De nition! Supporting domains A Supporting Domain (or Subdomain) are

    the areas of the business that play roles in making the Core Domain happen. Driver Routing (route me from X to Y)
  37. De nition! Supporting domains A Supporting Domain (or Subdomain) are

    the areas of the business that play roles in making the Core Domain happen. Driver Routing (route me from X to Y) Financial Transactions (charge the card, pay the driver)
  38. De nition! Supporting domains A Supporting Domain (or Subdomain) are

    the areas of the business that play roles in making the Core Domain happen. Driver Routing (route me from X to Y) Financial Transactions (charge the card, pay the driver) Optimization & Analytics (track business metrics)
  39. De nition! Supporting domains A Supporting Domain (or Subdomain) are

    the areas of the business that play roles in making the Core Domain happen. Driver Routing (route me from X to Y) Financial Transactions (charge the card, pay the driver) Optimization & Analytics (track business metrics) Customer Support (keep people happy)
  40. Apply It! Discover the domains on your diagram Look for

    clustered groupings. You might discover some domains you never even thought you had!
  41. Congrats - we've got a list of domains in our

    system And a rough mapping of what domain models go where.
  42. Now let's talk boundaries Boundaries in Rails: 1. Classes 2.

    Modules 3. Gems 4. Rails Engines 5. The Rails App 6. A separate app or API
  43. De nition! Bounded Context Concretely: a software system (like a

    codebase or running application) Linguistically: a delineation in your domain where concepts are "bounded", or contained
  44. Bounded Contexts allow for precise language Your domains may use

    con icting, overloaded terms with nuances depending on context
  45. Bounded Contexts allow for precise language Your domains may use

    con icting, overloaded terms with nuances depending on context Bounded contexts allow these con icting concepts to coexist
  46. class Trip def time # here be dragons... end def

    cost # here be dragons... end end
  47. Overloaded concept: Trip Time Financial Transaction Context: Trip time is

    calculated from vehicle moving time (minutes) Routing Context: Trip time is calculated from total passenger minutes, including stopped time
  48. Overloaded concept: Trip Time Financial Transaction Context: Trip time is

    calculated from vehicle moving time (minutes) Routing Context: Trip time is calculated from total passenger minutes, including stopped time Concepts share the same name, but have nuanced behaviors based on context!
  49. Overloaded concept: Trip Cost Financial Transaction Context: How much $

    the customer pays (dollars) Routing Context: Trip ef ciency (scalar coef cient)
  50. Overloaded concept: Trip Cost Financial Transaction Context: How much $

    the customer pays (dollars) Routing Context: Trip ef ciency (scalar coef cient) Concepts share the same name, but are wildly different!
  51. # Overloaded concepts! class Trip def time # Routing: total

    clock minutes # Financial: moving minutes end def cost # Routing: Routing AI subsystem efficiency metric # Financial: $$$ metric end end
  52. # A little workaround? class Trip def elapsed_time end def

    moving_time end def routing_efficiency_cost end def money_cost end end
  53. How could we x it? In DDD, we would introduce

    two Bounded Contexts: one for the Financial Transaction Trip another for the Routing Trip These Trips can now coexist within their own software boundaries, with all their linguistic nuances intact!
  54. Apply It! Overlay your bounded contexts Next up - with

    a different color pen or marker, draw lines around system boundaries / bounded contexts.
  55. Apply It! Overlay your bounded contexts Next up - with

    a different color pen or marker, draw lines around system boundaries / bounded contexts. You may also nd other system boundaries like: External cloud providers Other teams' services or systems
  56. You just made a Context Map! A Context Map gives

    us a place to see the current system as-is (the problem space), the strategic domains, and their dependencies.
  57. Making sense of the Context Map We may notice a

    few things: One bounded context contains multiple sub-(supporting) domains
  58. Making sense of the Context Map We may notice a

    few things: One bounded context contains multiple sub-(supporting) domains Multiple bounded contexts are required to support a single domain
  59. class Trip < ActiveRecord::Base belongs_to :vehicle belongs_to :passenger belongs_to :driver

    end class TripsController < ApplicationController # ... end
  60. module Ridesharing class Trip < ActiveRecord::Base belongs_to :vehicle belongs_to :passenger

    belongs_to :driver end end module Ridesharing class TripsController < ApplicationController # ... end end
  61. class PaymentConfirmation belongs_to :trip, class_name: Ridesharing::Trip belongs_to :passenger, class_name: Ridesharing::Passenger

    belongs_to :credit_card has_many :menu_items belongs_to :coupon_code has_one :email_job # ad infinitum... end
  62. De nition! Aggregate Root Aggregate Roots are top-level domain models

    that reveal an object graph of related entities beneath them.
  63. Apply It! Only expose aggregate roots Make it a rule

    that each domain only exposes Aggregate Root(s) publicly via: Direct method calls JSON payloads API endpoints
  64. Apply It! Only expose aggregate roots Make it a rule

    that each domain only exposes Aggregate Root(s) publicly via: Direct method calls JSON payloads API endpoints You may have multiple Aggregate Roots per domain.
  65. Apply It! Build service objects that provide Aggregate Roots Break

    dependencies on AR relationships Your source domain can provide a service that returns the Aggregate Root as a facade
  66. # Provide outside access to a core model # for

    the Ridesharing domain module Ridesharing class FetchTrip def call(id) Trip .includes(:passenger, :driver, ...) .find(id) # Alternatively, return something non-AR # OpenStruct.new(trip: Trip.find(id), ...) end end end
  67. # In the old world, we relied on AR relationships:

    module FinancialTransaction class PaymentConfirmation belongs_to :trip, class_name: Ridesharing::Trip belongs_to :passenger, class_name: Ridesharing::Passenger # ... end end
  68. # Now, cross-domain fetches must use the # aggregate root

    service: module FinancialTransaction class PaymentConfirmation def trip # Returns the Trip aggregate root Ridesharing::FetchTrip.new.find(payment_id) end end end # OLD: payment_confirmation.passenger # NEW: payment_confirmation.trip.passenger
  69. # Old way module Ridesharing class TripController def create trip

    = do_something_to_create_trip(params) # Uh oh, this isn't a Ridesharing concern ReallySpecificGoogleAnalyticsThing .tag_manager_logging('custom_event_name', ENV['GA_ID'], trip) end end end
  70. Apply It! Publish events if you need to do something

    in another domain Flip data dependency and instead broadcast that you did something. This lowers coupling between our domains!
  71. # Introducing... a Domain Event Publisher class DomainEventPublisher include Wisper::Publisher

    def call(event_name, *event_params) # Wisper then invokes registered subscriber # code at this point broadcast(event_name, *event_params) end end
  72. module Ridesharing class TripController def create trip = do_something_to_create_trip(params) #

    Here, we fire an event, but don't care # what actually happens next DomainEventPublisher.new .call(:trip_created, trip.id) end end end
  73. Apply It! Every bounded context has its own event handler

    Now we add an event handler for each domain, so it knows how to handle incoming events. This handler will then dispatch the relevant side effects for each event, through a Command object.
  74. # Handles relevant domain events. Dispatches to # Command objects

    that perform side effects. module Analytics class DomainEventHandler # Method name is invoked based on the name of the # message. This method is invoked in response to # the `trip_created` event. def self.trip_created(trip_id) # handle the action here, delegate out to a # service/command. LogTripCreated.new.call(trip_id) end end end
  75. # Hook up the handler (with a subscription) to #

    the DomainEventPublisher # config/initializers/domain_events.rb Wisper.subscribe(Analytics::DomainEventHandler, scope: :DomainEventPublisher)
  76. # Meanwhile back in the Analytics domain, we # wrap

    the specific GA call in a Command/service object. module Analytics class LogTripCreated def call(params) ReallySpecificGoogleAnalyticsThing .fire_event('custom_event_name', ENV['GA_ID'], params['trip']) end end end
  77. # Different domains can opt to subscribe to the same

    # events! module FinancialTransaction class DomainEventHandler def self.trip_created(trip_id) CreateTaxAuditLogEntry.new.call(trip_id) DeductGiftCardAmount.new.call(trip_id) end end end
  78. Apply It! Now make it truly asynchronous with ActiveJob! This

    has been synchronous so far - everything happens within the same web request thread. Wisper can hook into ActiveJob to truly process your events asynchronously in a worker queue. Everything after publish now is processed by a worker!
  79. Using a message queue Instead of using Wisper, publish a

    RabbitMQ event! Each domain's event handlers are run as subscribers to an exchange topic. Stitch Fix's Pwwka is an excellent Rails-RabbitMQ pub/sub implementation. You can also use Sneakers.
  80. Apply It! Sharing entities between contexts Shared Kernel - namespace

    shared models in a common module or namespace: User ➡ Common::User
  81. Apply It! Sharing entities between contexts Shared Kernel - namespace

    shared models in a common module or namespace: User ➡ Common::User This can later be packaged up in a gem if your systems are spread out
  82. Apply It! When you have one model that needs to

    belong in two domains Sometimes, you have a concept that needs to be broken up. How can we get these concepts codi ed in different domains? Concept: Anti-Corruption Layer
  83. Apply It! When you have one model that needs to

    belong in two domains Sometimes, you have a concept that needs to be broken up. How can we get these concepts codi ed in different domains? Concept: Anti-Corruption Layer We will introduce a notion of an Adapter that maps an external concept to our internal concept.
  84. # Legacy, complicated domain model module Common class Trip <

    ActiveRecord::Base def elapsed_time; end def moving_time; end def routing_efficiency_cost; end def money_cost; end end end # Nice, expressive domain model module Routing class Trip < Struct.new(:cost, :time) end end
  85. # Convert between a Common::Trip to a Routing::Trip module Routing

    class TripAdapter def convert(external_trip) attrs = mapping_from(external_trip) Trip.new(mapped_attrs[:cost], mapped_attrs[:time]) end def mapping_from(external_trip) { cost: external_trip.routing_efficiency_cost, time: external_trip.elapsed_time } end end end
  86. module Routing class TripRepository def self.find_by!(*params) external_trip = ::Common::Trip.find_by!(*params) TripAdapter.new.convert(external_trip)

    end end end # Module code now, instead of calling ::Common::Trip.find_by!, # calls Routing::TripRepository.find_by!
  87. Progressive refactoring 1. Domain-oriented folders, to... 2. Rails engines, to...

    3. Rails microservices with a shared AR gem and a message queue, to... 4. Fully-decoupled, polyglot microservices Each of these evolutions is simply modeling a bounded context with stronger seams!
  88. This may work for you if... DDD works well if:

    You have a complex domain that needs linguistic precision. You work in a very large (perhaps distributed) team You're open to experimentation and have buy-in from your Product Owner. The whole team's open to trying it out (not a lone wolf). Other teams, too.
  89. Know when to stop! Consider backing out if: You're getting

    that feeling of Overdesign™ The weight of maintaining abstractions is a heavy burden Other teams unhappy or lost
  90. Know when to stop! Consider backing out if: You're getting

    that feeling of Overdesign™ The weight of maintaining abstractions is a heavy burden Other teams unhappy or lost Don't pressure yourself to follow DDD patterns "by the book".
  91. In summary Discovered the Domains in our business Built a

    Context Map to see strategic insights Investigated some refactoring patterns to shape our systems.
  92. Credits & Prior Art Evans, Eric. Domain-Driven Design: Tackling Complexity

    in the Heart of Software. Gorodinski, Lev. "Sub-domains and Bounded Contexts in Domain-Driven Design (DDD)". Hagemann, Stephan. Component-Based Rails Applications. Parnas, D.L. "On the Criteria To Be Used in Decomposing Systems into Modules". Vernon, Vaughan. Implementing Domain-Driven Design. W. P. Stevens ; G. J. Myers ; L. L. Constantine. "Structured Design" - IBM Systems Journal, Vol 13 Issue 2, 1974.