Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
By Eric Roberts and Declan Whelan You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it's hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the "fat model, skinny controller" hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture. Declan loves to code and help others get joy from their code. When not coding he is the CTO at Printchomp, an agile coach at Leanintuit and an Agile Alliance Board Member. Eric Roberts is a software developer at Boltmade and co-founder at 20Skaters. He is enthusiastic about creating maintainable software. Help us caption & translate this video! http://amara.org/v/FG1q/
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 titled "Domain Driven Design and Hexagonal Architecture with Rails" features Eric Roberts and Declan Whelan discussing how to effectively apply design patterns in Rails applications to avoid common pitfalls like the "fat model, skinny controller" problem. ### Key Points Discussed: - **Introduction of Speakers**: Both speakers share their backgrounds, emphasizing their passion for coding and maintainable software. Declan, the CTO at Printchomp, describes his journey in adopting Ruby on Rails despite initially lacking expertise in the language, while Eric, a software developer at Boltmade, highlights his transition from front-end to back-end development. - **Challenges in Rails Development**: They discuss the typical structure of Rails applications, where the responsibilities of controllers, models, and views often become blurred, leading to complex and unmanageable code. They showcase an example of a 90-line method that encapsulates too much functionality, indicating the need for better organization. - **Domain Driven Design (DDD)**: Emphasizing the importance of understanding the domain of the application, the speakers explain DDD as a way of tackling complexity by creating a common language between domain experts and developers. They discuss using classes named after domain concepts such as "Customer" and "Product" to enhance clarity and reduce miscommunication. - **Hexagonal Architecture**: They introduce hexagonal architecture as a means to structure applications with a strong focus on domain logic. Layers like application-level code and various adapters connect to this core domain, emphasizing that different concerns (like database operations) should reside separately from business logic to promote more manageable codebases. - **Practical Patterns**: - **Form Objects**: Presented as an approach for handling complex form submissions where multiple models are involved, aiding clarity in controllers. - **Request Objects**: Discussed as a method for encapsulating request data and validations at the boundary of the system, helping to streamline controller logic. - **Service Objects**: Introduced to handle business logic cleanly, allowing controllers to delegate responsibilities effectively. ### Conclusions and Takeaways: - The speakers conclude by emphasizing the fun in understanding and improving complex systems through experimentation and breaking responsibilities into smaller parts. - They stress the need for Rails developers to look beyond their framework and familiarize themselves with broader software design principles that can be applied across different languages and platforms. The presentation encourages developers to adopt best practices in software design to create more maintainable and extensible applications while recognizing the inherent complexities in software development.
Suggest modifications
Cancel
