Creating an enterprise application involves many decisions. There are so many options, and with each decision, number of other options emerge. One way to reduce the scope to deal with is to organize the application into layers. For each layer in an application, there are different design considerations. These consideration and what impact each choice has, is one of the hardest tasks in architecturing enterprise software. Many things can be learned from textbooks although they are limited to a specific context, other things are learned from doing – experience. Sometimes hard and painful experience. While things look to be easy enough, when things start to operate with other things and scale, what sounded easy is actually not. In my 11th Lecture in the Design and Implementation of Software course, the goal is to look at the complete design from web layer to the database and how all the pieces come together, Application Architecture.
In the first section we look at the big picture and design consideration for each of the three principal layers. They are different concerns and considerations to think about. In the Web Layer its all about keeping the web presentation logic from the domain layer, and deciding what is on the gray area. We have to understand different client types. While back in them old ways people would run Windows native clients that accessed a server, today we have multiple of choices for clients. Sometimes we don’t even decide.
Native clients are one type, embedded another and interactive web application the third. All of these have similar ways to access the enterprise application. There is clear difference between the client and the server. API calls supply the content or the resources needed for the client. Note that I don’t make distinction between a native application (like Android or iOS or Windows) and interactive web sites. The web site needs to access the content with JavaScript. The last category of client type to mention is a simple servers side web site using a templating engine that generates HTML for a web browser.
Then there is different type of content. Content is not just content. A web site may have static content, editable content and dynamic content. The static content is any graphical asset that you might get from an graphical designer. Examples are logos, backgrounds, themes and things like that. These are not edited frequently and could be done all at once, for example if the web site changes themes. Then there is editable content. This content that the operator wants to edit, possible frequently. If your web site has lots of editable content, consider using a Content Management System. The last category is dynamic content. This is the domain data that is provides by the data in the database and any domain specific logic that manipulates the data.
For the domain layer the main consideration are where to put the domain logic. Two choices are presented. First is using an application server that is just a container for code. Other systems can look of the code and call it. EJB contains is an example of this. Most application servers (at least in the Java world) have web servers built in, so they do not need to be distributed. Another way is to use lightweight container. An example of that is the Spring application context that we have used in the course.
The considerations of the data source layer depend partly on the domain. The key is to allow structured access to the database. In the lecture we look at table gateways, which is a very common choice in enterprise software. Other choices are using Object-Relational Mapper tools, like Hibernate. These tools are by now very stable and can actually improve the data access due to the optimization that has been built in.
The slides and lecture video can be found here: Lecture L11 Application Architecture
Cover image by: wagaboodlemum
flickr.com/photos/72058777@N03/