Domain Driven Design in Ruby on Rails with emphasis on Repository Pattern

Transcript

1. Domain Driven Design With emphasis on Repository Pattern Application: Where do my domain objects come from and go to? Repository: That’s none of your business!
2. Rails Controller Layer ❖ Connects a request with a response, delegates all the business logic in between to the model layer, and the presentation logic to the view layer
3. Rails View Layer ❖ Takes data from a controller and assembles a response ❖ Some view layer components: ➢ Templates ➢ Partials ➢ Serializers ➢ View Helpers
4. Rails Model Layer ❖ All the business logic that takes place between request and response! ❖ Fat ActiveRecord models can only go so far ❖ DDD to the rescue!
5. Entity ❖ An object that is identified by its identity ❖ In other words, an entity has an identity ❖ Changing an entity’s properties does not change its identity ❖ Examples ➢ A user of an application with authentication ➢ A product in an e-commerce store
6. Value Object ❖ An object with values but lack an identity ❖ Should be treated as immutable ❖ Two value objects with the same values are indistinguishable ❖ Changing a value object’s properties yields a different value object ❖ Example ➢ A copy of a game that got sold (assuming simple case where individual game copies are not tracked)
7. Aggregate ❖ A collection of objects that are bound together by a root entity known as the aggregate root ❖ Objects external to the aggregate can only hold reference to the aggregate root and nothing else in the aggregate ❖ Changes to the aggregate are done through the aggregate root to ensure consistency
8. Aggregate (cont’d) ❖ Examples ➢ A ragdoll in a physics game ➢ A survey (with questions and responses) in a CRM software
9. Service ❖ Carries out an operation that does not conceptually belong to any object ❖ Examples ➢ A user purchases a product in an e-commerce application (ProcessTransaction) ➢ A new user registers in an application (RegisterUser) ➢ A user confirms an email verification (ConfirmUserEmailVerification)
10. Factory ❖ Carries out the operation of creating and initializing objects ❖ Not responsible for persisting objects that get created ❖ Example ➢ A BlogFactory that generates a blog from author, title and body text
11. Abstract Factory ❖ Specifies an interface for factories ❖ Example ➢ A phone abstract factory that creates or gets inherited by iPhone 6 factory, Nexus 7 factory, and Galaxy S6 factory
12. What about persisting objects?
13. Repository ❖ One of the major structural patterns encountered in DDD ❖ Mediator between application and data storage layers ❖ Solely responsible for fetching objects and persisting objects ❖ Exposes an interface that deals with object collections ❖ Usage is controversial with ORMs such as ActiveRecord
14. Benefits of using repositories ❖ An explicit layer that exposes data access to the application ➢ No query builders in controllers and models! ➢ Consistent query logic when queries are reused ❖ Flexibility of using multiple persistence strategies without spilling that knowledge to the application ➢ ActiveRecord, Raw SQL, Redis, MongoDB, memory, CSV, etc. ➢ Easy to swap ORM or change DB
15. ❖ Allow object access decisions to be clearly communicated ➢ User can only be retrieved by ID, username or email ❖ Hide multiple data sources! ➢ SoA with multiple distinct databases ➢ Aggregate of objects persisted in different databases? More benefits of using repositories...
16. An Example - DuckRepository