Home » Software Development » Multilayered Architecture (3) – The Application Layer

About Marco Di Stefano

Marco is a software engineer specialized in software architecture and process automation. He has been involved in all the software v-cycle phases and actually he works for the railway industry.

Multilayered Architecture (3) – The Application Layer


As Business Documents are considered the input for the Domain Layer, System Requirement Specifications are the main input document for the Application Layer. Scope of this layer is to provide an implementation of the defined requirements for the system. So it is easy to understand that most of the logic contained is process oriented and so linked to a specific system implementation.

What is a Business Process?

In a general view, a Business Process (or simply Process) can be considered as a composition of several tasks, that composed together following a certain flow responds to the goal of automate a specific functional requirement. A process is generally mapped to a specific requirement, so it does not have a good chance to be reused by other process (except when a parent process composes several smaller processes), but a single task instead will probably have. What are the different types of tasks a process can compose? We could think to identify 3 main types: Business Tasks, Utility Tasks and Application Task.

Business Tasks

As discussed in a previous post The Domain Layer, a Business Task is considered to be agnostic logic that is part of the business model of the designed domain. To give a clear example, all logic related to a Factory or a Repository or a Validation Rule is considered as Business Task. To deeper analyze, what we will have inside a Factory is logic that permits to create a Business Entity in a state that is immediately considered as business validated. This code will surely be used in several processes, where for example several entities must be created at once.

Utility Tasks

Utility task is the best example of agnostic logic, cause it is naturally not related to any specific process or entity, as it simply provide valuable and reusable logic. An example of a utility tasks can be a task that given two points return their distance, or given a text return a formatted text following a certain format condition. Where this code is located depends on its purpose: if it is related to certain domain entities it could be in the domain layer, or if not related to any domain entity could be in the application layer. Sometimes, when working in an enterprise-wide environment, could be also interesting to have another layer with only utility tasks, to permit to be reused and shared between different applications. In an SOA for example it is normal to have a category of services labeled as Utility Services residing in a separate layer.

Application Tasks

An Application Task accomplishes the implementation of logic that is in the System Requirements but is not part of the Business Model of the Domain. I usually try to apply this definition, even if it is not always clear specially when business and system documents are not well separated (and this is the most common case…). Another way to describe an Application Task is as logic that extends features provided by Business and Utility Taks.

 The Process Logic

Finally Process Logic is considered all that logic that simply composes several tasks in a pre-designed logic flow, handling Exceptions and managing Transactions. So a Process normally does not implement any pure logic, but simply composes existing logic into a new configuration; that is why we could also classify it as a Controller. Processes are considered the entry point for each interaction with the system. WS-BPEL for SOA is an example of Language for process definition. For a desktop application, Processes are what UI Actions will directly call.

Application Services

As the Application Layer should stay agnostic about the Infrastructure implementation, sometime is necessary to delegate the Infrastruture Layer to implement application logic defined in the Application Layer. This is simply done as for the Domain Layer by defining simply the interface of the logic and then use the concept of interface-implementation separation, as discussed in Multilayered Architecture, to recall the actual available implementation of the logic. The following figure shows a final picture of what an Application Layer could contain.



The Application Layer contains logic that in most of the cases is specific to a system implementation. Anyway, to foster Reusability, it could always be separated in small horizontal layers that could be reused and integrated in different applications. User Interface and Infrastructure related technologies should still be kept away from this layer.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments