The document discusses Domain Driven Design (DDD) focusing on the repository pattern, which acts as a mediator between the application and data storage layers. It highlights various design concepts like entities, value objects, aggregates, services, factories, and abstract factories, emphasizing the importance of having a dedicated repository for persisting and retrieving objects. Benefits include streamlined data access, flexibility in persistence strategies, and clearer communication of object access rules.

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