Enterprise Integration Zone is brought to you in partnership with:

Cagdas Basaraner is a software engineer graduated from Hacettepe University Computer Engineering department and Information Systems master program (Turkey). He has 5 years of professional experience, and is working on information systems with JEE web technologies. He is also a former developer of information systems with Microsoft .NET technologies and Command & Control (C4I) systems with Java technologies. Cagdas is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

Layers of a Standard Enterprise Application

02.21.2013
| 6064 views |
  • submit to reddit
In a standard enterprise application which has a database and graphical UI (web or desktop), there are some typical layers which constitute the application. In this article we will mention those layers and give some instructions about them.  The general diagram is as below:

There are some important properties about that diagram:  There are vertical and horizontal layers. Vertical layers may be thought as general application service libraries which can paralelly work on all horizontal layers and independent from each other. However, a horizontal layer's subject of interest is only its neighbour (top and bottom) horizontal layers, and they work sequentially from top-to-bottom and bottom-to-top. Lastly, user can only interact with topmost horizontal layer.  Horizontal layers:
  • Presentation: Every enterprise application has a UI, in fact graphical UI. This UI can be web or desktop based, which doesn't matter. The rule is simple. UI takes user action and sends it to the controller. And at the end it shows result taken from controller to the user. UI can be implemented according to MVC, MVP, MVVM or another approach.

  • Control: Handles business logic of the application. Takes info from user and sends it to DB layer (DAO or ORM framework) and vice versa. Abstraction type of controller may vary (a separate control and business layers for example)  according to the application parameters or development patterns (MVC, MVP, MVVM, ...) but the main idea remains the same.

  • Data Access: Database handling layer of the application. It may contain entity definitions, ORM framework or DB connection codes having SQL sentences, according to the abstraction decision. Its role is getting data from controller, performing data operation on database and sending results again to controller (if result exists). Database independence is a very important plus for this layer, which brings flexibility.

Vertical layers:
  • Security: Security is a general concept, which includes user authorization, user authentication, user role management, network or SQL injection attack prevention, data recovery etc but we grouped that items generally as "Security". Those issues must be handled for each horizontal layer if you want to have a fully secure software.

  • Logging: Logging is very important for maintenance and reporting in enterprise applications. An easily configurable, parameterized, readable, flexible and correctly implemented logging layer for all horizontal layers is very useful for both developers and users.

  • i18n: i18n (internationalization) brings multiple language support and user interface text changing capability without rebuilding code. It may also have localization property which can handle number, currency and date formatting. So i18n provides flexibility on appliations and should not be ignored.

  • Exception Handling: Exception handling may also be included in "Security" or "Logging" layers. We should not use only general exception classes or absorb all exceptions if we want to develop a quality software. We sometimes need our special exception classes with their specific behaviours for better security, logging and application performance.

If you design an architecture which has that layer structure considering software quality factors (which are told here), you will probably have a successful enterprise software application.
Published at DZone with permission of Cagdas Basaraner, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Peter Hofman replied on Thu, 2013/02/21 - 8:37am

Depending on which framework or standard you use, you might be missing a few layers:

  • horizontal layers: business processes and/or business services.
  • vertical layers: governance; and maybe even business activity monitoring, unless you see logging as such.

I have seen Enterprise application with:

  • horizontal layers: presentation; interaction; business logic; mediation; data access.
  • vertical layers: as you listed.

but also with:

  • horizontal layers: presentation; business process; business services; data access; connectivity.
  • vertical layers: security; common services; governance; monitoring; service bus.

It would be nice to know which standard you are talking about here, since you named it standard enterprise application.

Andreas Schilling replied on Thu, 2013/02/21 - 9:59am

Hhmm, I'm missing the domain model in your diagram.

At least in our case (rich clients) the domain model is usually also one of the vertical layers which is quite natural if you use any sort of ORM. Some people might argue this is a violation of layering, but as long as you don't use ugly crap like active record I think this is perfectly fine.

Parts of the domain model that are not plain mappings from database tables (often simply transport objects that are compositions of base objects) or that can't be put into the vertical layer because they would introduce layer responsibility violations are then kept in the interface parts of the respective layers which can only be accessed from the layer above.

So, we usually have something like

UI -> [Business_Interface/Business_Implementation] -> [Data_Access_Interface/Data_Access_Implementation] -> Database

This layering is easy to force with OSGi when only the interface parts can be accessed from the higher levels. Of course each layer can again be split into subparts when single modules of the application are that complex that they justify having their own bundling.

Thang Chung replied on Thu, 2013/02/28 - 6:45am

It is just a simple architecture for enterprise system. I think we should think about distributed system architecture as well. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.