Laying the Foundation of the Application Layer

Feb 16, 2015

Table of contents:

1. What is the Application Layer?
2. Why is the Application Layer important?
3. What does the Application Layer consist of?
4. Should all applications have an Application Layer?
5. Conclusion

Since the reboot of this series into being more “Domain Driven Design” focused, we’ve mostly concentrated on the Domain of the application.

We have touched upon implementing a couple of services for certain aspects of the application, but for the most part we’ve focused on building out the Domain layer.

This means that the majority of the code that we’ve written so far is sitting in isolation.

I like the approach of building out the Domain layer in isolation, but it comes to the point when we need to start building out the Application layer to join everything up.

Now that Laravel 5 has officially launched, we can start to look at building out the higher layers of the application.

This means writing the Application Services, creating the Domain Events and building out the HTTP layer to accept and return responses.

In today’s tutorial we’re going to be looking at the Application Layer in more depth, what is it, and why is it important in an application?

What is the Application Layer?

The Application layer is an important part of an application’s stack, but it can be easy to confuse the role it plays.

The Application layer is the front line of your application. It sits behind the HTTP layer to offer an agnostic interface in and out of your application.

When a request comes in, the Application layer converts that request into an accepted format and then passes it to the relevant Services and Domain objects within the application.

After the request has been processed, the Application layer is responsible for passing out a response that can be handled by the layer above it.

Why is the Application Layer important?

The Application layer coordinates the various objects and services of your application and acts as an agnostic interface to the application.

This means your application is theoretically just like an API that accepts certain types of requests and returns certain types of responses. The internal implementation of the application is not the concern of the outside world.

Therefore theoretically, this should allow your application to be “driven” in any number of different ways. Typically this would be through a HTTP framework such as Laravel, but it doesn’t really have to be.

Whilst this is a noble goal, it probably isn’t going to make a difference to the majority of applications.

However I think having the separation between the outside world (the HTTP framework) and your application is good because the lines of responsibility are clear.

What does the Application Layer consist of?

So hopefully now the purpose the Application is clear, but what exactly does the Application consist of?

Well, I don’t think there is a clear definition of how the Application layer should be technically implemented.

However, the majority of examples that I’ve seen use either Application Services, a Command Bus, or a combination of the two.

An Application Service is just a generic service class that encapsulates the action to be executed. The Service will accept the request, coordinate the various components required to satisfy the request, and then return a response.

A Command Bus on the other hand accepts the request and then passes it to a specific Command Handler. The Command does not return a response. I’ve written previously on using a Command Bus in Creating and Using a Command Bus.

I want to build the client-side of the application using Ember.js, so I’m also going to need to build in a JSON transformation layer to convert responses to the correct format.

Should all applications have an Application Layer?

No! Small applications do not need this kind of abstraction. Over-engineering is a bad thing and will cost you more than the perceived benefits of the abstraction.

Having multiple layers, and clear separation is a really good thing in bigger applications. But superfluous indirection will just make certain applications harder than it needs to be.

If it’s important for your application to have an agnostic interface, or if you want to provide that clear division of responsibility, having an Application layer is the perfect solution.

But it is probably over-kill for a whole host of web applications.

Conclusion

I think having a clearly defined Application Layer is a very interesting concept in web applications.

By providing a clean and clear line of separation between your application and the framework I think it makes it really easy to “get under the hood” of your code.

This boundary also acts as an agnostic interface so “driving” your application should be a lot clearer. Instead of having to fire up a web browser and hit a Controller you can equally drive the application from the command line.

However, using an Application Layer is certainly not a silver bullet.

You are also adding in a layer of indirection that can make your application more difficult to understand.

Over the next couple of weeks we will be going over each of the Domain to build out the Application Layer.

This is a series of posts on building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.