DZone
Web Dev Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Web Dev Zone > Organizing Your Domain Services

Organizing Your Domain Services

Jose Asuncion user avatar by
Jose Asuncion
·
May. 23, 12 · Web Dev Zone · Interview
Like (0)
Save
Tweet
2.50K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Published at DZone with permission of Jose Asuncion, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Why Is Software Integration Important for Business?
  • How Database B-Tree Indexing Works
  • Maven Tutorial: Nice and Easy [Video]
  • Memory Debugging and Watch Annotations

Comments

Web Dev Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo