Variation
Written by Oleksandr Sydorenko
Updated at May 5th, 2025
It’s common to see the layered architecture pattern extended with an additional layer: the service layer.
Service layer
Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation.
—Patterns of Enterprise Application Architecture4
The service layer acts as an intermediary between the program’s presentation and business logic layers. Consider the following code:
namespace MvcApplication.Controllers
{
public class UserController: Controller
{
...
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(ContactDetails contactDetails)
{
OperationResult result = null;
try
{
_db.StartTransaction();
var user = new User(); user.SetContactDetails(contactDetails) user.Save();
_db.Commit();
result = OperationResult.Success;
} catch (Exception ex) {
_db.Rollback();
result = OperationResult.Exception(ex);
}
return View(result);
}
}
}
The MVC controller in this example belongs to the presentation layer. It exposes an endpoint that creates a new user. The endpoint uses the User active record object to
 |
4 Fowler, M. (2002). Patterns of Enterprise Application Architecture. Boston: Addison-Wesley.
create a new instance and save it. Moreover, it orchestrates a database transaction to ensure that a proper response is generated in case of an error.
To further decouple the presentation layer from the underlying business logic, such orchestration logic can be moved into a service layer, as shown in Figure 8-6.
 |
It’s important to note that in the context of the architectural pattern, the service layer is a logical boundary. It is not a physical service.
The service layer acts as a façade for the business logic layer: it exposes an interface that corresponds with the public interface’s methods, encapsulating the required orchestration of the underlying layers. For example:
interface CampaignManagementService
{
OperationResult CreateCampaign(CampaignDetails details); OperationResult Publish(CampaignId id, PublishingSchedule schedule); OperationResult Deactivate(CampaignId id);
OperationResult AddDisplayLocation(CampaignId id, DisplayLocation newLocation);
...
}
All of the preceding methods correspond to the system’s public interface. However, they lack presentation-related implementation details. The presentation layer’s responsibility becomes limited to providing the required input to the service layer and communicating its responses back to the caller.
Let’s refactor the preceding example and extract the orchestration logic into a service layer:
namespace ServiceLayer
{
public class UserService
{
...
public OperationResult Create(ContactDetails contactDetails)
{
OperationResult result = null;
try
{
_db.StartTransaction();
var user = new User(); user.SetContactDetails(contactDetails) user.Save();
_db.Commit();
result = OperationResult.Success;
} catch (Exception ex) {
_db.Rollback();
result = OperationResult.Exception(ex);
}
return result;
}
...
}
}
namespace MvcApplication.Controllers
{
public class UserController: Controller
{
...
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(ContactDetails contactDetails)
{
var result = _userService.Create(contactDetails);
return View(result);
}
}
}
Having an explicit service level has a number of advantages:
• We can reuse the same service layer to serve multiple public interfaces; for exam‐ ple, a graphical user interface and an API. No duplication of the orchestration logic is required.
• It improves modularity by gathering all related methods in one place.
• It further decouples the presentation and business logic layers.
• It makes it easier to test the business functionality.
That said, a service layer is not always necessary. For example, when the business logic is implemented as a transaction script, it essentially is a service layer, as it already exposes a set of methods that form the system’s public interface. In such a case, the service layer’s API would just repeat the transaction scripts’ public interfaces, without abstracting or encapsulating any complexity. Hence, either a service layer or a business logic layer will suffice.
On the other hand, the service layer is required if the business logic pattern requires external orchestration, as in the case of the active record pattern. In this case, the ser‐ vice layer implements the transaction script pattern, while the active records it oper‐ ates on are located in the business logic layer.
Terminology
Elsewhere, you may encounter other terms used for the layered architecture:
• Presentation layer = user interface layer
• Service layer = application layer
• Business logic layer = domain layer = model layer
• Data access layer = infrastructure layer
To eliminate confusion, I present the pattern using the original terminology. That said, I prefer “user interface layer” and “infrastructure layer” as these terms better reflect the responsibilities of modern systems and an application layer to avoid confu‐ sion with the physical boundaries of services.