The purpose of this document is to describe the Repository layer and how it will be used in this application.

The Repository layer designed as an insulator layer separating the business logic (described in the Controller) and the core database access layer (described in the Model). It's meant to house the data logic for a set of operations involving the database. To illustrate:

Controller <------> Repository <-------> Model

So if something happens (like I want to switch out models to a different ORM, or I want to mock the models in some way), I can switch where the Repostiory is pointing to using dependency injection.

I'm reading up on this pattern - and I thought I knew how this worked, but this has opened my eyes a bit: https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/

It's using a much more organized structure, and allows for SQL criteria to be injected and used by the controllers. I think it's missing something, though - the Controllers still feel polluted by data logic. In order to make it domain driven, I'm thinking of another layer:

Controller <-------> Service <-------> Repository <-------> Model

...but it feels like overkill - a lot of the Services would all look relatively the same with little to diffrentiate (except in some special cases). All, this runs the risk of reducing the effectiveness of the RESTful mechanic and tend more towards an RPC model. Also, Criteria would most likely only be used within the repository layer.

The more I read about DDD (Domain Driven Design), the more that I think that I don't have all the pieces yet. I think it would actually be better as

Controller <-------> Ubiquitous Language <-------> Repository <-------> Model

Also, I need to look into the other parts of DDD (like Value Objects - POPOs?, and event driven)

....to be contondered!