Service Layer

As for calculating Order totals etc. Your Service layer would be the natural home. A SalesOrderCalculator class with LineTotal(LineItem lineItem) and OrderTotal(Order order) methods would be fine. You may also wish to consider creating an appropriate Factory e.g. OrderServices.CreateOrderCalculator() to switch the implementation if required (tax on order discount has country specific rules for instance). This could also form a single entry point to Order services and make finding things easy through IntelliSense.

Royd Brayshay http://stackoverflow.com/questions/1933351/if-you-are-forced-to-use-an-anemic-domain-model-where-do-you-put-your-business

Most SERVICES discussed in the literature are purely technical and belong in the infrastructure layer. Domain and application SERVICES collaborate with these infrastructure SERVICES. For example, bank might have an application that sends an e-mail to a customer when an account balance falls below a specific threshold. The interface that encapsulates the e-mail system., and perhaps alternate means of notification, is a SERVICE in the infrastructure layer. ... It can be harder to distinguish application SERVICES from domain SERVICES, The application layer is responsible for ordering the notification. The domain layer is responsible for determining if a threshold was met--though this task probably does not call for a SERVICE, because it would fit the responsibility of an "account" object. ... Funds transfer has a meaning in the banking domain language, and it involves fundamental business logic. Technical SERVICES should lack any business meaning at all.

Domain-Driven Design

Service: A service is a group of related functionality. Think of it as if you are splitting your architecture horizontally, you have a "Business Logic" layer, if you split that vertically you will have services.

Matt Briggs - http://stackoverflow.com/questions/1849618/difference-between-a-factory-provider-and-a-service

Your service layer methods should reflect the actions that you need to accomplish from a business sense. Frequently I find that my controller Actions match up very closely to service methods.
In your example, I would have the service build and relate to the necessary entities and talk to repos to save them; that way if there is a problem along the way of talking to the repos it can roll itself back and do whatever cleanup is necessary.
Repos should be relatively dumb. Services should do the relationship and business work (barring something like NHib, and maybe even then).

Chad Ruppert - http://stackoverflow.com/questions/1562247/how-much-resposibility-should-my-repository-service-have

Services are used to fetch information from a data source (most likely a repository), process the information and return the result to the caller.
A service class can use multiple repositories to achieve the wanted result. In this layer you can also have a event system which can allow one service to take actions when another service have generated an event.
An example would be that the the UserService calls the FeedService to create a new RSS feed item for each newly created user. ..
Keep in mind that having a Save(myBusinessObject) method in a service can make it hard to extend the application later on. It's better to have methods like IncreateTax, AttachToGroup etc. A Save method is a bit too general (in most cases) –

jgauffin - http://stackoverflow.com/questions/5015925/correct-use-of-repository-service-classes

• We'll have a layer of stateless business logic services that implements common algorithms or logic, unaware of the UI, but very much aware of (and delegating to) the domain model.
  http://stackoverflow.com/questions/4708689/ddd-where-to-put-persistence-logic-and-when-to-use-orm-mapping

Services perform tasks that the object cannot do for itself. One distinction is that services can access data stores. Your ProductId problem is a pretty good example: if ProductId were a Guid, it would be fine for Product to issue a ProductId in its constructor. In your case, you need to get ProductId from another system so you should enlist a service. – Jamie Ide

 http://stackoverflow.com/questions/756849/ddd-dependecies-between-domain-model-services-and-repositories

Services should care only about the problem domain, not the view that renders results. Return values should be expressed in terms of domain objects, not views.

duffymo - http://stackoverflow.com/questions/3002168/should-a-service-layer-return-view-models-for-an-mvc-application

1. The service layer is inherently integration code and, as such, most suitable for integration testing (rather than unit testing).
   The advantage of services talking directly to ISession is simplicity, and the ability to use the power of the framework chosen (NHibernate).

http://www.udidahan.com/2008/02/15/from-crud-to-domain-driven-fluency/

It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

http://martinfowler.com/bliki/AnemicDomainModel.html

In DDD, Services are not the holders of all business logic. They only represent verbs, actions of the domain that are cross-concern to several objects and thus wouldn't fit into one of the entities or aggregate roots without breaking single responsibility principle and creating tight couplings that would muddle the entity.

 ian31 -  http://stackoverflow.com/questions/5214220/ddd-sample-cargorepository-store-could-be-used-in-a-controller