Services and Repositories in DDD (C#)

Question

How do Services and Repositories relate to each other in DDD? I mean, I've been reading up on DDD for the past 2 days and everywhere I go, there's always a Service layer and there's always a Repository layer. How do these differentiate or compliment each other?

From what I've read, isn't the Repository the layer responsible for delegating interactions between the application and the data?

So, what's the need for the Service layer if it has to implement the Repository to interact with the data anyway even though the Repository probably already implements the methods needed to do so?

I'd appreciate some enlightenment on the subject.

PS Don't know if this will help any, but I'm working with an ASP.NET MVC 2 application in which I'm trying to implement the Repository pattern. I just finished implementing the Dependency Injection pattern (for the first time ever)...

UPDATE

Okay, with so many answers, I think I understand what the difference is. So, to review (correct me if I'm wrong):

• A Repository layer interacts only with a single object out of the database or the ORM, IEmployeeRepository -> Employee .

• A Service layer encapsulates more complex functionality on objects returned from Repositories , either one or multiple.

So, then I have a sub question. Is it considered bad practice to create abstract objects to be sent to my views? For example an AEmployee ( A for abstract because to me I means interface ) which contains properties from Employee and X or X ?

Actually, one more subquestion. If a Service layer can be considered "tuned" for an application does it need to be implemented with an interface?

Answer 1

服务将使用存储库检索实体，然后在其上调用方法（实体）以执行命令/任务。

Answer 2

True, a repository works with data (ie. SQL, Webservice etc.) but that's the only job. CRUD operations, nothing more. There is no place for stored procedure based busines logic.

The service (or business logic layer) provides the functionality. How to fullfill a business request (ie. calculate salary), what you have to do.

Oh, and this is a really nice DDD book: http://www.infoq.com/minibooks/domain-driven-design-quickly

Answer 3

As a concrete example a Shopping Cart application might have the following services:

ShoppingCartService - manages a cart of items with add/remove/update support etc.

OrderService - take a cart, converts it to an order and handles the payment process etc.

each of these services needs to talk a "data source" for CRUD operations. This is where the Repository pattern comes in handy as it abstracts the loading and saving of data to and from the data source be it a database, web service or even in-memory cache.

When you want to create a quick prototype of your application without having to deal with database setup, schema, stored procedures, permissions, etc. you can create a cache or fake repository in a matter of minutes.

For the example above your prototype might start off with the following:

• FakeCustomerRepository
• FakeAddressRepository
• FakeCartRepository
• FakeCartLineItemRepository
• FakeOrderRepository
• FakeOrderLineItemRepository

once your prototype is ready to evolve to the next level you can implement these against a real database:

• SQLCustomerRepository
• SQLAddressRepository
• SQLCartRepository
• SQLCartLineItemRepository
• SQLOrderRepository
• SQLOrderLineItemRepository

Answer 4

From what I can remember, the repository is the final class before the data. The service class can act on data retrieved from the repository. The repository is really just meant to get data to somebody else to do the work. The service layer can provide things such as business logic that all data must pass through. It could also provide for a translation between the application logic and the data layer. But again, this is just what I can remember.

Answer 5

There's no golden standard that defines a service or a repository. In my applications a repository is (as you say) an interface into a database. A service has full access to a repository - but the service exposes a subset of functionality to its consumers.

Think of the repository as more low level. The repository has to expose many ways of accessing the underlying database. A service might combine calls to a repository with other code that only makes sense at a code level (ie not in the database), such as access to other state in the application, or validation/business logic that can't easily be applied in a database.