Which layers should speak Domain Models?

Question

Let's say I have a method like this in my business layer:

// This is in the business layer
public Result DeleteSomeDomainObject( ???? )
{
   //Enforce business logic here.

   //Delete records in the database
   DAL. DeleteSomeDomainObject( ??? )
}


// This is in the data access layer
public Result DeleteSomeDomainObject( ???? )
{
   // Delete records from the database.       
}

Should these methods take instances of the domain model or just the primary keys?

Answer 1

Anywhere that's reasonable, it makes sense to decouple the policy from the implementation. I would say that if you plan to use some sort of ORM, pass instances of your business objects.

Answer 2

I struggle with this often. I usually say that your business/service layer should take domain objects as parameters.

If we are talking web, your web tier will have the ID. It will likely instantiate or retrieve an instance of the object from the service layer. So it makes sense to pass it to your service layer.

However, there are often times where you would end up duplicating the retrieve of the object. Sometimes your services will be loading an object anyways because of some additional data not captured in the web layer. I've even had times where the data access layer has to load objects for dependencies. Caching can solve some of these issues and re-architecting your data/model can fix others. Certainly. But sometimes, in light of performance or other issues, passing an ID just makes more sense.

To summarize, prefer passing domain objects to the business tier. But realize that for other reasons, you might be better off passing an ID and, unfortunately, there needs to be exceptions to your rule.