CODEWITHSUNDEEP
javajakarta-eedomain-driven-design
LuckyLuke
LuckyLuke

Reputation: 49077

Repository layer in DDD

I read this article and I have a question about it.

The Repository pattern is a Facade, that abstracts your persistence away from your Domain. On one side it pretends to be a collection – on the other it deals with the technical concerns of your persistence implementation.

Does that mean that you name the methods in repository as you would if you made a collection. For example:

addDomainModel(...)
getDomainModel(...)

and so on? Or would you name the methods:

saveDomainModel(...)
fetchDomainModel(...)

What would be best, or most correct? And should I have the method names saying what it adds, or just:

add(...)
get(...)

as it would in a normal collection?

http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx

Upvotes: 0

Views: 2204

Answers (2)

tahagh
tahagh

Reputation: 807

One of the goals of DDD, is that domain experts can READ the code. So you should name your methods to make your code more readable. From this point of view, in my opinion, itemRepository.add(item) or even items.add(item) is more understandable than e.g. itemRepository.saveItem(item). Look at this:

How to Write a Repository

Upvotes: 0

MikeSW
MikeSW

Reputation: 16348

There is no requirement for that. You name the methods in the most natural way for usage. Usually my repository looks like this (c# code)

public interface ImCommandRepository
{
    Entity Get(int id);
    Entity Get(string name);
    void Save(Entity value);
    void Delete(int id);
}

public interface ImQueryRepository
{
    PaginatedResult<ViewModel> GetEntitiesA(int skip,int take);
    PaginatedResult<ViewModel> SearchEntitiesB(string keyword,int skip,int take);
}

As you see I'm using different repositories for updating persistence and for querying persistence. While the first one has pretty much common CRUD methods for deaing with entities which will be created/updated/deleted, the other one just lists or searches the db and returns a model suitable for views. You can add or name methods depending on the usage, you don't HAVE to implement the repository as a collection (i.e implementing a predefined interface), just treat it like one. The important thing is to keep the domain agnostic from the persistence implementation.

Upvotes: 1

Related Questions