00:00:11.790
I'd like to ask you guys to introduce yourselves with one sentence, and maybe explain why you think you're an expert on the topics we're discussing today.
Hi, I'm Andrzej, and I've been working with Ruby on Rails for over ten years now. In this panel, I might be more of the Rails expert. My experience with event sourcing is only one year, mostly thanks to Mirek. I believe I can serve as a good connector between the Rails and event sourcing worlds. I've found that our community can gain a lot from implementing event sourcing, which was my topic of focus last year. We've tried incorporating it in many projects recently, and it seems to bring really good results for Rails applications.
00:01:00.690
Sorry to interrupt, but could you clarify whether you mean Rails applications or PHP applications?
I'm a PHP expert, actually. I do write a lot of code in PHP. Regarding the specialized topics of this panel, I have more experience working with event sourcing in the platforms we are building. I'm in charge of the component that manages customer billing, and in those types of applications, event sourcing is particularly useful since there's no such thing as a unique truth when working with payment gateways.
Having a system based on event sourcing for handling payments and billing helps us understand the nuances of specific transactions, especially when customers need support and want to know about their accounts. We can elaborate more on that later.
00:01:41.219
Oh, hi everybody! I'm Mirek. I'm very much focused on understanding the complexities of distributed systems. I'm into Domain-Driven Design (DDD), and I utilize various styles of DDD mainly as a way to decompose and understand problems. I believe that if I do my work well, creating robust systems and ensuring they perform efficiently becomes almost trivial. It's often the case that we make problems more complicated just to appear brilliant when we solve them.
Last year, I was still a .NET developer, so you can imagine I wasn’t hired because of my Rails or PHP skills. I’m interested in event sourcing and CQRS, and I hope to persuade more developers to adopt these practices.
00:02:59.349
Can you define in two sentences what event sourcing is?
Event sourcing is storing the data of your application as a series of events rather than just the current state. This allows you to reconstruct the current state of the system from the events that have occurred. Can you briefly explain CQRS?
CQRS stands for Command Query Responsibility Segregation. Essentially, it means dividing your system into parts that handle commands, which modify data, and queries, which read data. This separation typically results in different models for the write side and the read side of the application.
00:04:10.370
Let me add something: you usually tell a small portion of the system to perform an operation, like adding an item to the cart, while reading involves various aspects such as pricing and catalog information. This eliminates the need for creating an object solely for reading data; instead, you need objects for behaviors. Combining both reading and writing models often complicates design unnecessarily.
It's also quite challenging to explain CQRS to Rails developers because they typically lack the pain points that developers from other domains like .NET experience. In Rails development, we don't have the same depth of layers, whereas in .NET, for instance, you might interface with various layers: application service, domain layer, and data access layer.
00:05:57.840
If you want a structured application layout like this in Rails, both parts—write and read—must pass through all layers, which necessitates a lot of code simply to navigate through the different layers. In contrast, reading data in CQRS becomes significantly simpler; it involves directly querying the database and displaying the results. On the writing side, however, implementing commands is more complex, as you need to handle domain validations and ensure proper persistence of the command. It’s exactly in these contexts where CQRS becomes more apparent, making it easier to justify to developers why they shouldn’t just rely on Active Record.
00:07:27.500
So what about DDD? Can you give a one-sentence definition? DDD encourages putting learning before coding; it highlights the importance of understanding the problem before jumping into writing code. This is crucial, especially in complex and evolving domains, where understanding the real problem is key.
00:08:42.360
Do you have successful experiences implementing these patterns in Ruby applications? I believe there are no obstacles to using these patterns across different technologies. You can apply them regardless of the tech stack you choose. For instance, I worked on a simple Rails application where we incorporated events and event sourcing, which only took a few lines of code to implement. It’s really quite straightforward.
00:10:05.990
To clarify, I’m not asking whether you can apply these concepts in Ruby; rather, I wanted to know how you’ve successfully implemented them outside of a typical Rails way of structuring applications. Our team initially built a typical Rails project, but soon we introduced service objects. This was followed by implementing repository patterns to adapt our data handling approaches, which significantly improved organization.
At one point, we implemented domain events—a practice where interesting occurrences in the system trigger further actions. This feature helped streamline communication across various parts of our application, enhancing flexibility and responsiveness to changes. We saw a notable improvement in the application’s scalability and maintainability once we integrated domain events.
00:12:37.440
Let's discuss the technology side. I'm building software for my own company based on Sinatra and developed a library to manage event sourcing, aggregates, and repositories. While it took a lot of time to ensure that all parts fit well together due to my somewhat novice experience with Ruby, the results have been promising. Adding new requirements led to a decrease in development time, which contrasts with other applications where adding features tends to increase complexity.
00:15:49.380
The question is: when should we introduce DDD and CQRS into our applications? Does it matter whether we're at the beginning, middle, or end of a project? My approach would be to introduce these concepts as soon as you're familiar with them. Initially, learning about CQRS and event sourcing can be slow, but once you grasp the ideas and implement them, reusing the event store can become straightforward and beneficial.
I believe Alberto's insights yesterday provided a good connection between requirements gathering and coding, indicating that it's crucial to integrate domain events no matter what phase your application is in.
00:17:36.420
Could you clarify when event sourcing and CQRS should not be used? I would argue that they are inappropriate primarily for straightforward CRUD applications. However, even in less complex domains, the benefits of separating read and write operations still justify their use. Different contexts lead to varying meanings of identical data, and once developers become accustomed to recognizing domain events, it opens avenues for enhanced application structure. For example, splitting applications along bounded contexts can guide their transition into microservices.
00:19:52.950
In discussions, I often hear the phrase 'it’s just a simple CRUD application.' Yet, upon examination, such applications often contain complex interactions that are obscured by their apparent simplicity. This suggests that they may not be simple instances at all but rather involve significant architectural decisions that must be recognized to avoid complications later.
Additionally, there are numerous nuances surrounding concepts such as event sourcing and applying best practices. It's very easy to fall into the trap of presenting an application as simple while it secretly accumulates complexity under the hood.
00:22:32.520
I agree with your assessment regarding the complexities often masked within so-called simple applications. On one hand, the distinction between projections and aggregates is important; projections are used for understanding the system from a reader's perspective, whereas aggregates concern interactions tied to behaviors within the domain. Bounded contexts are also instrumental in clarifying operational definitions and integration points within a distributed system.
00:24:20.180
As technology evolves, it increasingly supports implementing CQRS and event sourcing practices. However, different layers of abstraction such as command handlers and repositories may blur distinctions across active, reading, and writing elements within software design. Clarity regarding purpose within architecture proves invaluable in ensuring that developed solutions align with business needs.
00:26:48.150
To sum up, tracking what an application needs will invariably reflect how we model information. Being cognizant of the demands and tailoring our structures to accommodate those realities will ensure success in real-world implementations. Appropriate use of event sourcing alongside a well-managed architecture serves to deliver optimal applications that can confidently evolve.
00:28:31.680
Thank you all for sharing your insights. Now we have some questions left, which we can tackle during the break. Please feel free to approach us with any questions regarding implementations or experiences, especially concerning concepts like Active Record and PHP.
