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.