Repository returns domain objects and is built on top of mapping layers. For a very simple domain domain objects and database tables can be very much the same.
If your repository is always returning exact representation of your data structure then it might actually be Table Data Gateway aka Data Access Object(DAO).
Example:
Your database has tables for person and address. In your application domain address is not an entity of it's own, it is just a property of Person. In this case you would not have PersonRepository and AddressRepository. You just have PersonRepository. Domain should not be concerned how the domain data is persisted. Those responsibilites are in a layer behind repository.
From your example it would seem you actually have DAOs and have just named them Repositories.
CRUD is an acronym that stands for Create, Read, Update and Delete. Those are the four basic operations that you can perform on a database tuple. But there's always more to business applications than creating, reading, updating and deleting database records.
Let's start with some basic definitions, and then look at a couple of examples and see how those definitions map to the examples, and how they map to actual software.
Business logic or domain logic is that part of the program which encodes the real-world business rules that determine how data can be created, stored, and changed. It prescribes how business objects interact with one another, and enforces the routes and the methods by which business objects are accessed and updated.
Business Rules describe the operations, definitions and constraints that apply to an organization. The operations collectively form a process; every business uses these processes to form systems that get things done.
Now, let's work with some examples.
Transferring money from one checking account to another
First, what are the things that you need to know (input)?
- The identity of the person making the transfer
- The amount of money to be transferred
- The source checking account number
- The target checking account number
What are some of the "business rules" that must be applied?
- The person making the request must have the authority to do so.
- The transaction must be atomic.
- The transaction may have reporting requirements to the government, if it is over a certain amount
By "atomic," I mean that the transaction must completely succeed or it must completely fail. You can't have account transactions where money is taken out of one account without arriving in the other (money disappears), or money is deposited into an account, but not debited from another account (money magically appears from nowhere).
Ordering something from Amazon.
What do you need to know?
- The identity of the person ordering
- Shipping information
- Billing information
- Method of Payment
- Amount and quantity of each item to ship
- How to ship (overnight, slow boat or super saver)
- State Tax Rate
What happens after the order is placed?
Items are pulled from stock
On hand quantities are debited
Items are packaged for shipment
Out of stock items are backordered
Items that drop below minimum quantities are ordered
One shipment or two?
An invoice/shipping list is printed, and placed with the order
..etc.
Best Answer
Well, you can see a good example in the Spring Data Framework which is based on the concept of repositories.
There you will see repositories only deal with the data store, and rarely contain any business logic (this is reserved for the service layer). So, for instance, you take a look a their design you will see they have a CRUDRepository interface which exposes methods to create, destroy and recover entities (among other things). There is also a PagingAndSortingRepository that adds extra functionality for precisely that, sorting and paging results, etc, etc.
So, this framework is perhaps a good place to study a good repository design.
As far as I know, many of the concepts implemented by the Spring Data Framework, come from a great book called Domain-Driven Design: Tackling Complexity in the Heart of Software, the book has an entire section dedicated to Repository design.
You may consider getting a copy of it.
A small excerpt from the book explains: