What types of code are appropriate for the service level?

Question

Suppose you have entities, a service level, and repositories (with ORM, for example, NHibernate). User interfaces interact with the service layer.

What types of code are appropriate for the service level?

---

Repository coordination?

It seems that entities should not reference a repository , therefore there should be calls for loading / saving / sending entities at a service level?

Business logic involving repositories?

If the above value is true, should there be something like checking if the username is different at the service level (i.e., calling GetUsersByUsername and checking the results)? Before assuming that the database should handle different ones, how about checking that the password has not been used for 90 days?

Business logic that includes multiple entities?

I'm not sure about this, but I will say that you need to apply the operation against a collection of objects that may or may not be related and are not actually applicable to a single object. Should entities be able to work in these collections, or does something like that belong to the service layer?

Mapping?

If you use DTO or send your objects to / from your service level, you will most likely finish the mapping (preferably with AutoMapper). Does this relate to service level?

---

I am looking for confirmation (or rejection) of the above ideas, as well as any other thoughts about the responsibility of the service level when working with entities / repositories.

Answer 1

Storage coordination?

Aggregate roots should draw transaction boundaries. Therefore - it is rarely necessary to use several repositories. If they are, this usually happens when you create a new aggregated root (as opposed to changing its state).

---

Business logic that includes repositories?

Yes, checking if username can be different can be in the service layer. Because the user is usually the aggregate root and the aggregate roots that live in a global context (there is nothing that “held” them). I personally put such logic into the repository or just check directly through ORM.

As for checking the use of the password - this is the problem of the user himself and should live under the User object. Something like that:

class User{ void Login(){ LoggedOn=DateTime.Now; ... } bool HasLoggedInLast90Days(){ return (DateTime.Now-LoggedOn).Days<=90; } } 

---

Business logic that includes multiple entities?

The aggregated root must manage its collections of entities.

 class Customer{ void OrderProduct(Product product){ Orders.Add(new Order(product)); //<-- } } 

But remember that the aggregate root should not microcontrol its essence.

eg. This is bad:

 class Customer{ void IsOrderOverdue(Order order){ return Orders.First(o=>o==order)....==...; } } 

Use instead:

 class Order{ void IsOverdue(){ return ...; } } 

---

Mapping?

I assume the mapping in dto`s is in service mode. My mapping classes live next to the kind of model classes in a web project.