Organizing Your Domain Services

I have always though that it was easy to name your services e.g if you had a User domain object then you would surely have a User Dao and a User Service. If I had a user domain object reading my articles domain object and I wanted the user to keep track of read articles, I would expose the act of tracking read articles as a method of a user service.

But I don’t think it’s always the case.

For one, it can be the owner that returns some domain object as a service. For example if I had an article domain object and they were being published by a magazine domain object and I wanted to get a list of a magazine’s articles, I prefer to use a magazine service which exposes a getArticles() method rather than an article service that requires an array of ids in a getArticles() method. I’d rather use the article service to perform operations to an article domain object like for example find or analyze perhaps. But to retrieve a group of articles, I think filtering by magazine is the best way to go and then passing in some other filtering options in an array like category.

To see what I mean in terms of code, rather than do this:

class ArticleService {
   public function getArticles(array $ids) {
     // implem
   }
}

class CategoryService {
   public function getArticles($categoryID) {
      // implem
   }
}

class MagazineService {
   public function getArticles($magazineID) {
      // implem
   }
}

I’d rather do this: 

class MagazineService {
   public function getArticles(ArticleAccessBean $accessBean) {

  }
}

class ArticleAccessBean {
  private $articleID;
  private $categoryID;
  private $magazineID;

  // setter and getter methods

}

At the end of the day, I take my cue from this blog post which has some wonderful advice for naming your services. I am quoting its advice here:

Domain services are the coordinators, allowing higher level functionality between many different smaller parts. These would include things like OrderProcessor, ProductFinder, FundsTransferService, and so on. Since Domain Services are first-class citizens of our domain model, their names and usages should be part of the Ubiquitous Language. Meanings and responsibilities should make sense to the stakeholders or domain experts.

In many cases, the software we write is replacing or supplementing a human’s job, such as Order Processor, so it’s often we find inspiration in the existing business process for names and responsibilities. Where an existing name doesn’t fit, we dive into the domain to try and surface a hidden concept with the domain expert, which might have existed but didn’t have a name.