Software Application Layers And Responsibilities

By Ben Nadel on December 21, 2012

Tags: ColdFusion

I know that I haven't done much blogging lately (due to work); but, I've been doing a ton of thinking about software application architecture. Much of this thought has been influenced by previos projects as well as the pain and subsequent refactoring of my current project. On top of that, the people who comment on this blog have been extremely influential in shaping the way that I am coming to understand application architecture. That said, as we close out 2012, I wanted to take a few minutes to outline my current feelings about how I see the application layers and what their respective responsibilities are.

Right now, I am thinking in terms of building software with the following layers:

• Controller Layer
• Application Layer
• Domain Layer
• Infrastructure Layer

Before I get into the details of each layer, let me make some broad sweeping philosophical statements:

• Each of the above layers depends exclusively on the layer immediately below it.
• Outside of entities (ex. Linked Lists), circular references are to be avoided. The more I think about it, the more I tend to feel that circular references are a sign that I am missing orchestration at a higher level of the application.

That said, let's look at each layer. Because I am still forming all of these thoughts in my head, I'm going to write mostly in bullet-points. I don't think my understanding is refined enough to write technical prose.

Controller Layer

• It is the public face of the application.
• It routes incoming requests and returns responses.
• Both incoming and outgoing data is restricted to simple data types (ex. structs, arrays, numbers, strings, etc.). This could be JSON, HTML, XML, binary, AMF, etc..
• It performs high-level security and authentication. Since different requests may be using different forms of identification (ex. cookies, HTTP Basic Authentication, oAuth, SAML), it is the Controller's responsibility to orchestrate the transformation of request data into authentication data.
• The Controller layer may invoke the application layer to help with authentication. However, if requirements are simple enough (ex. Basic Authentication for 3rd-party Web Hooks), the controller layer may perform its own authentication.
• It is the only part of the entire application that knows about session management.
• It is very thin, using the Application layer to perform most of the work.

Application Layer

• It is the programmatic boundary of the application.
• It accepts and returns simple data structures. However, unlike the Controller layer, it probably shouldn't deal with data like JSON or HTML. Rather, it deals with non-serialized data structures and relies on the Controller to serialize and deserialize data representations.
• It performs low-level security and checks access permissions. In the case of a request made by a user, the application would be responsible for checking whether or not the requesting user has the right to perform the given action (ex. can this User delete that Publication).
• All methods in the application layer that can be invoked by a user's request should require the authenticated user ID as the first argument.
• It orchestrates Transactions management.
• It orchestrates workflow, but defers to the Domain Layer to carry out each step of the workflow.
• It is moderately thin and defers to the domain layer for the bulk of its logic.

Domain Layer

• It contains the "business logic" of the application.
• It maintains data integrity.

NOTE: Since I don't currently deal with "domain entities," my thoughts on the domain layer are, by far, the least evolved. I typically deal with domain services and raw data structures.

Infrastructure Layer

• It provides adaptors for technologies such as persistence, file systems, email, Twitter, Twilio, Pusher, etc..
• It deals with simple data structures (ex. structs, arrays, numbers, strings, binary, etc.).

So, right now, as of Dec 21, 2012 at 5:05 PM, this is how I see application architecture. I am hyper-specific about the time since my understanding and thoughts about software application architecture are constantly evolving. I've come a long way in 2012 (I think); I hope that 2013 brings new levels of enlightenment and understanding!