Introduction
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.
Conclusions
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.
