I’m going to give my take on a very common layered architecture diagram like the one below. I don’t think this diagram is a perfect example of what layers belong where, but I’ll save that to the end. I think there’s value in giving some details on each one without being too picky on how the diagram needs to look.
There are many resources out there for figuring out what belongs in each layer. I am going to focus on the why the layer exists and how to determine what belongs in it.
What it is
All aspects of the code that the user or component client sees or interacts with. This could be a web site, a mobile application, a desktop application, a console application or whatever technology that comes next.
Why is its own layer
The way you present your application, should not change your application. The application should be able to work regardless of the mechanism you choose to interact with it. This is important for a few reasons.
- Technologies are going to change over time and you are going to want to change with them. You should be able to tinker with the presentation without having to change anything in the application. In fact, you should be able to completely replace your front end design if you so choose.
- You may want to move your code to a native mobile application or a console app. If this were to happen, you should not need to rewrite any of the same application logic.
Helping Answer “Does this belong in the Presentation Layer?”
- Does the code rely on a certain I/O Technology? Web, Mobile, Desktop etc.?” If so it belongs here.
- This layer shouldn’t directly do anything business related. All that work should be delegated to the application layer classes.
- You can still have business object names in your classes, so long as they are not “doing stuff” business related. The “stuff” should be functionality for presenting data.
- Any designer or marketer that has influence over the “look and feel” of your application, should be limited to this portion of the code base. If a change to “look and feel” causes you to rework some business logic, you probably have some code in the wrong area of the system.
What it is
This is everything that makes the application useful outside of the user interface. This is also where the business logic mixes with the technical details, but only if the technical details can be reused in different presentation layers.
Some diagrams may also refer to this layer as the “use cases” for the business objects. This also makes sense, as we don’t want our business objects to be coupled to each other. The “use cases” are going to refer to entire sequences of steps abstracted into method calls for the presentation layer.
Why it is its own layer
This layer is going to contain everything that needs to be coupled to technology, so its really what is left over from the presentation layer and the business layer. If something can be decoupled from use cases or technical details, it should be a part of the business layer.
An example of how we distinguish the above and below layers.
- Presentation Layer: Android application music application.
- Useful for android users.
- Application Layer: Music Application Web Service with various methods: GetAllMusic, GetAllPlaylists, GetFavoriteMusicByUser, etc.
- Useful for any presenter that needs to call a web service.
- Business Layer: Music, Playlist and Security libraries containing classes and business rules.
- Useful for any music application we want to create
Helping Answer “Does this belong in the Application Layer?”
- If this is a core business rule, it should belong in the business layer if possible.
- Service or Controller classes typically belong in this layer, these are often performing a sequence of steps related to different business entities.
- All of the code that makes an application “work” behind the scenes.
What it is
The business entities in their simplest form. These are the building blocks used by the application layer to create an application.
Why it is its own layer
The application layer is going to need to change frequently. As more requirements, refactoring and optimizations occur, your core business logic should remain the same. This layer will be shielded from those technical decisions. This layer will be flexible and will avoid most of the complex architecture decisions.
Helping Answer “Does this belong in the Business Layer?”
- If you had to show a business user how the product works in the code, this is your BEST chance to show them some code they may actually understand
- Business functionality in this layer should be less likely to change then business functionality in the application layer.
- A client using code from this layer should be able to build any application they can think of. No technical decisions will have been made for them.
- Consider coding as if this were to be created as a third party library.
- The Application layer, works out of the box, but inflexible
- The Business layer, is the “do it yourself” kit
- These are much smaller and specific libraries, your application classes and methods are likely going to reference many business libraries. Your business libraries should avoid that.
Data Access Layer
What is it
This layer has one job, and it is to contain the classes in functions that persist the business entities in the layer above.
Why it is its own layer
- How we save things should not be a concern to the business
- Just like the presentation layer, how you save your application should not change your application
- Like the presentation layer, could contain business object names, but should not make business decisions
Helping Answer “Does this belong in the Data Access Layer?”
- Ideally there should be no business logic in this layer, but sometimes unavoidable for performance reasons. If performance is not an issue, the logic should not be added here.
- Product managers, sales, marketing or other business stake holders should not be influencing any decisions made in this area of the code base.
What I don’t like about this chart is that the data access layer is listed at the bottom. I see it more at the application layer level. Persisting data is something you are choosing to do as part of the application. However, often times you’ll want to reference the data access layer from the business entities. It works so long as its flexible enough to change later.
The toughest decisions to make are between the application and business layers. There are going to be times where you have “core business logic” that can’t be decoupled from technical details. The layer between application and business will be something that evolves as your application evolves.
A key role in all of this are using interfaces to keep logic separated. It is impossible to keep layers decoupled without them. Perhaps that is something to discuss in detail in a future post.