Microservices
Panel: Event-driven Rails
Edit
See all speakers
See all 4 speakers
#event-sourcing
#domain-driven-design
#event-driven-architecture
#ruby-on-rails
#software-architecture
#team-collaboration
#microservices
Summarized using AI

Panel: Event-driven Rails

Scott Bellware, Nathan Ladd, Andrzej Krzywda, and Paweł Pacana • September 19, 2023 • Wrocław, Poland

The video titled "Panel: Event-driven Rails," features a discussion among experts Nathan Ladd, Andrzej Krzywda, Paweł Pacana, and Scott Bellware at the wroc_love.rb 2023 event. The panel blends a standard discussion with open debate on event sourcing within Rails applications, notably contrasting their perspectives on domain-driven design (DDD). Here's a structured overview of the key points discussed:

  • Introduction to Event Sourcing: Scott and Nathan introduce their work with Eventide, a tool for event sourcing in Rails, while Paweł and Andrzej explain their role with the Race Event Store. They emphasize the theme of engaging with the audience on event sourcing practices.

  • Divergence on Domain-Driven Design (DDD): Nathan raises a pivotal question about the panelists' differing views on DDD. While he endorses its principles due to their alignment with event sourcing and Command Query Responsibility Segregation (CQRS), Scott critiques DDD for its complexity and suggests that it has become overly trendy, leading to confusion in developers' understanding.

  • Power of Vocabulary in Software Design: Scott and Paweł highlight that jargon can create barriers to understanding, stressing the importance of using clear language that aligns with fundamental software principles instead of overly specialized terminology. They argue that complex vocabulary can obfuscate business logic, making testing and communication harder.

  • Importance of Clear Business Logic: The panelists reflect on the need for clarity in business logic coding. They propose that event sourcing can facilitate the decoupling of concerns, thus allowing better communication between developers and business stakeholders.

  • Collective Understanding in Development Frameworks: They discuss the need for developers to grasp foundational principles of software design rather than becoming consumed by frameworks or patterns. This understanding, they argue, will help create robust and maintainable systems.

  • Summarizing Key Insights: The concluding thoughts emphasize that software design should serve logical applications rather than be viewed as mere implementations. They encourage continued discussions and openness to various software development approaches while staying true to sound principles.

In summary, the panel advocates for a balanced approach to software design that prioritizes clear communication, effective coding practices, and a nuanced understanding of fundamental principles over the tendencies of over-complication through frameworks or jargon.

Key Takeaways:
- Embrace clarity in design while avoiding jargon-heavy language.
- Focus on business logic and effective communication.
- Continue dialogue on best practices to evolve software craftsmanship.

Panel: Event-driven Rails
Scott Bellware, Nathan Ladd, Andrzej Krzywda, and Paweł Pacana • September 19, 2023 • Wrocław, Poland

wroclove.rb 2023

00:00:02.700 Welcome to the event-driven Rails discussion panel. This session is a blend of a standard discussion panel and an open debate. Here, we like to confront ideas. To provide some context, Scott and Nathan are behind Eventide, a tool designed for event sourcing in Rails, while Paweł and I are responsible for the Event Store. So, we have a clear division, but how many of you are using event sourcing in your systems? It seems like not many. So, we can consider ourselves the ‘event sourcing team,’ and you are somewhat our opposition. We're excited to engage with you in this discussion.
00:00:39.180 Throughout our talk, we will discuss our tools and paradigms, and there may be some vocabulary differences that we want to address. We’ll ask questions of each other but are also open to any challenging questions from the audience, especially to Scott. I think it's a good idea for us to introduce ourselves briefly before diving into questions.
00:01:12.960 Scott, why don’t you start?" Scott: "Hi, I’m Scott Bellware, co-founder of the Eventide project and Message DB. Both are tools we use for event-driven systems development. Message DB is a tool for PostgreSQL used by Eventide, which is a toolkit built in Ruby. My background is in software testing, software design, user experience, architecture, and management. I worked with Nathan on a project for a law firm in Silicon Valley that involved venture capital.
00:02:30.239 Pawel: "I’m Paweł Pacana. I have been working on the Race Event Store as a maintainer and release manager for over five years. My experience revolves around legacy software, so I often deal with codebases that carry their history, which makes integrating the Race Event Store quite interesting. Nathan, you also gave a presentation earlier today about test benching. In addition to that, I work closely with Scott on Eventide projects. We assist existing projects in overcoming difficulties. For example, we developed the Race Event Store to support existing Race projects. Some of you participated in the workshop yesterday, where we discussed an e-commerce application built using Event Store along with domain-driven design and event sourcing practices. That’s a brief overview of our work and background.
00:03:59.820 Nathan: "It’s clear we have different views on domain-driven design (DDD). We’ve embraced DDD in our projects because we find the underlying techniques quite useful. While we may not subscribe to every single technique, DDD often pairs well with event sourcing and CQRS. However, I know you have voiced your opposition to DDD while you support event sourcing and event-driven architecture. We share similar approaches, yet I’d like to open with this question: Why not domain-driven design?
00:04:37.520 Scott: "I think it’s because DDD has become cliche. It consists of elaborate patterns that can consume a developer’s thought process, often leading to a narrow mindset. I started exploring DDD in 2002 and even delivered talks on it, but I don't hold onto that zeal. While I find some principles valuable, many aspects have been distorted for celebrity status in tech, creating a captive audience that struggles to escape. Whether it's frameworks like Rails or others, there’s often unnecessary complexity that arises from these celebrity-driven tools.
00:06:07.680 I agree that DDD’s essence—its core design principles—are important. However, I caution against the elaborate patterns that have emerged. Nathan and I presented at the Explore DDD conference in 2018, discussing the mistakes inherent in many tactical patterns, revealing that if certain patterns have measurable flaws, they should be dismissed. Developers need a broader vocabulary that encompasses universal software principles rather than specialized jargon from one subculture.
00:07:24.840 Paweł: "It’s interesting that you emphasize vocabulary. New terms can create noise rather than clarity. You can lose significant knowledge if you adopt jargon without understanding its origins. What’s more, there's power in aligning language with established principles of software development rather than isolating yourself in a jargon-heavy space.
00:08:17.980 Scott: "Absolutely. The challenge arises when a community leans into terms that may have shifted in meaning over time and alienate mainstream understanding. Being clear and precise in our vocabulary is crucial to ensuring ideas are conveyed accurately. The fundamental concepts from DDD existed well before its popularization and are applicable across various software disciplines. While gaining new insights from DDD can be transformative, I think care should be taken not to become too enmeshed in any one ideology, lest we restrict ourselves.
00:09:47.640 Paweł: "You mentioned that wrapping technical implementations in new terms can hinder actual communication. I agree that the essence of certain terms and concepts from DDD can be valuable, but when they become cloaked in niche vocabulary, they lose their effectiveness. We should create language that allows us to bridge gaps between various software development practices rather than box ourselves into exclusive terminologies.
00:11:22.020 Nathan: "Right, and while we are talking about vocabulary, we also need to explore the implications it has on our actual coding practices. When we frame our business logic poorly—using complex vocabulary—it often obfuscates the true nature of the systems we're developing, leading to difficult testing scenarios. I worry that developers may become fixated on adopting a pattern instead of focusing on clean, effective communication to convey the business logic.
00:12:18.920 Scott: "Definitely! Taking shortcuts to simplify design can often lead to complications down the line. When each new technology or pattern brings its own complexities, the effort should always be made to design components independently and transparently. Relying on new jargon may cloud our judgment rather than aid us.
00:14:09.979 Paweł: "I think we should focus more on understanding the business logic we’re writing, and translating that into our code. Events can help decouple concepts effectively, allowing us to maintain clear boundaries between different areas of concern within the application. This way, we can provide clarity for both developers and business stakeholders.
00:14:43.850 Scott: "I agree! The challenge is that different components need to work cohesively together, respecting boundaries without blurring lines. This can be manageable through a robust understanding of how best to structure systems from the start, rather than relying on patches for systems that have become entwined. We thrive when we see the fundamental physics of good software design.
00:15:42.040 Paweł: "As we transition from theory to practice, we need to understand that as frameworks evolve, so too must our appointments between them and core principles. Above all, we should strive for a solid foundation where complex systems don't originate from tangled components but rather distinct domains working harmoniously together.
00:16:51.380 Scott: "Summing up this discussion, the most valuable insight is understanding that software design shouldn’t be treated as a set of Serials to be implemented, but as an application of logic providing a service. Our group should be willing to pivot toward maintaining and not sacrificing fundamental truths for quick gains. Conversations like this one can help us step back and reassess our approaches moving forward.
00:18:29.040 Paweł: "Exactly! We must realize that legacy systems often restrain our progress and that we must uphold a clear vision in how we tackle design decisions as software evolves. Developers need to challenge both their thoughts and the expectations imposed by frameworks to ensure they are not shackling their creativity with models that have limitations.
00:19:07.660 Scott: "Absolutely! As new technologies will undoubtedly arise and old paradigms shift, let’s continue this dialogue where openness toward different approaches allows the evolution of our craft to thrive. Thank you for an engaging and thought-provoking conversation, everyone.
00:19:41.960 Paweł: "Thank you, all, for joining us in this discourse. It’s clear we all share an underlying goal: pushing the boundaries of software development while ensuring we’re equipped with the right tools and mindsets to maintain productivity without losing sight of principles that matter most.
Scott Bellware
@sbellware
Nathan Ladd
@ntl
Andrzej Krzywda
@andrzejkrzywda
Paweł Pacana
@mostlyobvious
Explore all talks recorded at wroclove.rb 2023
+10