Designing the Service Layer

At this point in our application design discussion, we have a way of representing the data in our problem domain so that we can manipulate it in code, and we have a way of storing this data in a database and then getting it back out later. However, currently we are not doing much with this data. Unless your application is especially simplistic, chances are some kind of logic needs to be implemented. Earlier, we discussed cases where you should encapsulate logic inside your domain objects. In this section, we look at providing a layer of service objects to provide a standard interface to the rest of your application logic.

Why Have a Service Layer

As with the question as to why you should have a data access layer, the answer to this question is plain and simple once you have implemented a few applications without one. If you do not bring together all the business logic in a single place, it ends up spread out through your presentation code, typically resulting in lots of code duplication, not to mention creating code that lacks clearly defined boundaries for responsibilities. Code duplication issues aside, failing to define clear boundaries between code with different responsibilities often results in code that is difficult to trace and maintain, because it becomes hard to pinpoint the location of a given function.