Search
Ruby on Rails
Built to last: A domain-driven approach to beautiful systems
Edit
#domain-driven-design
#refactoring
#ruby-on-rails
#software-architecture
#microservices
#code-organization
#team-collaboration
Summarized using AI

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

Andrew Hao • May 10, 2017 • Phoenix, AZ

In his talk at RailsConf 2017 titled "Built to last: A domain-driven approach to beautiful systems," Andrew Hao discusses strategies to enhance the longevity and maintainability of software systems, specifically within a Rails codebase. He emphasizes moving beyond traditional refactoring patterns to a domain-driven design approach, which helps in identifying boundaries specific to business domains. Key points covered include:

  • Understanding Beautiful Systems: Beautiful systems are those that are built to last, with precise boundaries that are highly cohesive and loosely coupled.
  • Context Mapping Exercise: This strategic design tool helps visualize and articulate domain boundaries, allowing for modular system development.
  • Ubiquitous Language: Establishing a shared vocabulary within teams promotes clear communication and design precision, aiding the development process.
  • Identifying Domains: The talk highlights the importance of distinguishing core domains from supporting domains, using examples related to the fictional DeLorean time travel app.
  • Refactoring Patterns: Incremental refactoring through organized namespaces and service objects minimizes dependencies and enhances system interactivity.
  • Bounded Contexts: These contexts allow teams to work independently, each focusing on their specific area of the business, thereby reducing confusion over similar terms across different domains.
  • Event-Driven Architectures: Hao introduces the concept of decoupling systems by using event-driven strategies, which facilitate communication between different domains without tight coupling.
  • Complexity vs. Clarity: The presentation stresses that in some cases, the sophisticated nature of a system may require added complexity for clarity, contradicting the usual quest for simplicity.

By applying these concepts, developers can create more manageable, scalable, and resilient systems that evolve alongside business needs. The key takeaway is to cultivate a deep understanding of the business's domain-specific language and architecture to build systems that can withstand change over time.

Built to last: A domain-driven approach to beautiful systems
Andrew Hao • May 10, 2017 • Phoenix, AZ

RailsConf 2017: Built to last: A domain-driven approach to beautiful systems by Andrew Hao

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!

RailsConf 2017

00:00:00.030 Welcome to your first day at DeLorean! You're going to love it here. At DeLorean, we're revolutionizing the industry of time travel. With just one push of a button on our app, you can summon a driver in a DeLorean, and they will come roaring around the corner. You jump in, and you get taken to whatever time period you want.
00:00:15.900 Now, I should mention that it might be a little messy for you because we have a lot of teams here. You might be surprised when you open the codebase, but don't worry; it's totally normal to feel a bit overwhelmed when you first join. One thing you should know is that we have several of these codebases. When you implement a feature, you'll need to check out multiple codebases. Furthermore, we have some funny naming conventions around here; for example, when your product owner tells you about the 'fizz bang widget,' don’t forget it’s actually called the 'fubar doohickey.'
Andrew Hao
@andrewhao
Explore all talks recorded at RailsConf 2017
+109