Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
This video was recorded on http://wrocloverb.com. You should follow us at https://twitter.com/wrocloverb. See you next year! Slides: http://www.slideshare.net/emadb/wroclove-rb Emanuele Delbono with FROM ACTIVERECORD TO EVENTS We are used to write our rails application with ActiveRecord and store in the database the current state of our entities. This kind of storage is not lossless as we might think, we completely miss the story that took the entities in the current state. That's way new architectures are becoming popular, these architectures don't store the state of the models but their deltas. During this session we will give a look at the Event Driven architectures, what problems they solve and how can be implemented in ruby and rails applications.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
The video 'From ActiveRecord to Events' by Emanuele Delbono, presented at the wroc_love.rb 2014 event, explores the limitations of traditional ActiveRecord models in Rails applications and advocates for the adoption of Event-Driven Architectures, particularly Event Sourcing and CQRS (Command Query Responsibility Segregation). ### Key Points: - **Traditional ActiveRecord Limitations:** - ActiveRecord tightly couples application models to database structures, complicating persistence as applications scale. - Inner workings of modern applications can become convoluted due to the mixing of data and behavior in domain models that lead to anemic entities. - **Domain Model Challenges:** - Difficulty in handling complex models: a large domain model can create a monolith that makes it hard to separate concerns. - The N+1 query problem arises during lazy loading, violating the Single Responsibility Principle as models handle both data persistence and domain logic. - **Shift from CRUD to Business Operations:** - Emphasizes the need to move away from traditional CRUD thinking and focus on user-driven business operations. - **Command Query Responsibility Segregation (CQRS):** - Proposes separating read and write operations into different models, allowing for performance enhancements and clearer business logic handling. - Describes a system with command handlers for processing business logic and separate read databases optimized for querying. - **Event Sourcing:** - Suggests moving from a state-based model to an event-based approach that captures changes as discrete events, enabling the reconstruction of past states and providing insights. - Illustrates Event Sourcing as a way to maintain historical records, resembling the function of a bank statement detailing all transactions. - **Implementation Structure:** - Highlights a design utilizing message buses for decoupling command handling from the application while ensuring events reflect changes accurately. - Discusses the storage of events in a dedicated database (e.g., MongoDB) and the synchronizing of read databases for efficient querying. - **Complexity and Trade-offs:** - While Event Sourcing provides numerous advantages such as clarity and encapsulation, it may introduce complexity, especially in simpler applications where the overhead may outweigh benefits. - Addresses challenges in managing long-lived objects by suggesting periodic snapshots to handle extensive event histories efficiently. ### Conclusion: Delbono's talk encourages developers to consider Event-Driven Architectures as powerful alternatives to the limitations of ActiveRecord, stressing that understanding how to separate business operations from database operations is crucial for building scalable and maintainable Rails applications.
Suggest modifications
Cancel
