An introduction to some of the concepts in Domain Driven Design with a specific emphasis on Repository Pattern, and how to apply them in Ruby on Rails.

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!
Presented at November Ruby Lightning Talks T.O.

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

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

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.

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