The Architecture Layer

Posted in: MySQL, Technical Track

Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.

    • Presentation
    • Application
    • Business Logic
    • Persistence (also called Storage)

The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:

A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.

It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it’s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.

I will call this merged business/application layer the “functional layer.”

The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.

“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”

Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.

This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].

This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(‘Sheeri’,’hair color’,’blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.

For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.

The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.


Interested in working with Sheeri? Schedule a tech call.

6 Comments. Leave new

I’ve added this to the Oracle and SQl Server categories as I don’t think this interesting idea is at all dependent on the database platform and I would like to check in with the other communities we participate in to see how they see this.


I’ve had the same thoughts about this. People separate things by MVC, and this and that…

I’ve thought of it and I believe I call mine the “Data Access Layer” (for lack of a better term so far) – it is the go-between from the applications and the datastore. “Datastore” could be a hybrid memcache/MySQL solution, sharding, clustering, flatfiles – it doesn’t matter.

As long as there is a proper user_set() call and a user_get() call – the only two ways to modify and access that data, then it will be transparent to the layers above it where exactly the data came from.

Some day I will actually try to make some graphical explanation of this and some example code to sanity check myself and have people pick it apart, but so far on any of the projects I have approached it seems to be a good approach.

Sheeri Cabral
May 13, 2008 5:42 pm

Thanx Paul — I think it’s an important way technology is changing, that it’s more and more relevant to think of an “architecture” layer.

Dominic Brooks
May 14, 2008 3:01 am

Do you see which database the data goes into or comes from as distinct from which web server an http request goes via?

Is it a layer or a cloud or just a virtualisation of resources?

A functional layer certainly should not care whether there is one or ten databases nor which particular database Sheeri with the blonde hair colour is in; you can make a good case for saying that a persistance layer not either.

But sometimes it’s not just about databases is it? You want requests about blondes to go down an entire architectural leg including app server, etc.

Tony Marston
May 14, 2008 4:09 am

The idea of having a separate business and application layer does not appeal to me at all. I have used the 3 Tier Architecture in two different languages, so I use nothing more than a presenation layer, business layer and data access layer. The phsical database an be switched from one DBMS to another simply by changing the data access object (DAO).

Your example of the ACCOUNT_NUMBER logic having to appear in multiple places shows a flawed implementation. You should have a single ACCOUNT object which contains the necessary logic to insert, update or delete any ACCOUNT instance, and whenever an instance has to be manipulated it should be done so via the ACCOUNT object. There may be many calls to the ACCOUNT object from many places, but the logic inside that object is defined once and need never be duplicated.

Sheeri Cabral
May 14, 2008 8:43 am

Mike — yes! although I think it’s important to distinguish between how the data is stored, meaning how the schema is designed, and where the data is stored, meaning the physical architecture. Even though the application might call a function in the “data access” API, that data access API to me has 2 parts — the structure of the data (db, table, column for a relational database), and the server on which to store it on.

I absolutely agree that changes in the schema and/or the architecture should be transparent to the application — the data access API doesn’t change. By the same token, though, if the schema changes, the architecture does not, and vice versa. So whatever makes up what you call the “data access” layer needs to encompass both, and an architecture change should only change the “here’s how to find out what machine to connect to” parts, whereas a schema should only change the “here’s which db(s), table(s) and column(s) to query” parts.

Dominic — good point. I guess it’s similar to a smart load balancer for http. When you go to, DNS and Google’s webserver configuration point you to a particular webserver. Similarly, when an application “goes to” a database, it should be directed where to go by external logic — that logic is the architecture layer.

For me, coding the architecture layer into the functional layer (app/business logic) is like never using DNS and hand-configuring your /etc/hosts file for every single website you go to. It works, but any architecture change requires you to change your /etc/hosts.

Tony — I’m not sure if you read the whole post, but the whole point of the article that I quoted was that the business and application layer don’t need to be separate, for exactly the reason you stated.

I explicitly stated that I agreed with the article and would, for the course of this article, refer to the merged “business/application” layer as the “functional” layer. Hope that clears things up.


Leave a Reply

Your email address will not be published. Required fields are marked *