- The document discusses repository patterns, domain-driven design (DDD), and unit testing. - It notes that using a repository allows testing logic separately from the database engine and vice versa. This separates concerns and makes mocking easier. - DDD is introduced as a way to model complex domains by representing entities and value objects. - Unit tests should test one class at a time in isolation by replacing dependencies with mocks to avoid complexity. - The document concludes by stating it will provide code examples.

1. Introduction
Repository, DDD & Unit Tests

2. Agenda
- Repository
- DDD
- Unit Test
Case Study : Working on Laravel 5.0

3. Stories
- I want to test the data logic but i dont care
the data engine (database)
- I want to test the data engine (database) but
i dont care the data logic
automated tests...

4. In Reality

5. Problem?
“ the power of united data logic and database, called ORM “

6. Real problem?
As programmer we have to make sure every
single unit should be working properly..
the keyword is -> every single unit of our code

7. Repository

8. Benefit?
- We can test logic without engine
- We can test engine without logic
- We can test the repository it self
easy to mocking…
separation of concerns...

9. DDD
Solve complex needs by modelling the domain

10. DDD Things
- Entity. Unique object
- ValueObject. Immutable object

11. Example
Users data that contain their credentials like
email, username and password.
In DDD:
User is an entity, password can be a
ValueObject.

12. Unit Test
1 class 1 responsibility
We should can test each of 1 class without
thinking the dependency complexity (replace all
dependency with mock)

13. Enough!
SHOW ME THE CODES!