Over a million developers have joined DZone.

Dependencies in a Three Tiered Application

· Java Zone

Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems, brought to you in partnership with AppDynamics.

When people working on a multitiered application get asked to draw their architecture, often something like this emerges:

UI -> Domain -> Persistence

This is all nice until you start to wonder what the arrows actually mean.

Is it data flow? Probably not, except when you are working on an application that takes input, stores it somewhere but never retrieves it back.

Is it dependencies? Hopefully not, or everything depends on your persistence layer. You really don’t want that.

It might be calls: The UI gets triggered by the user in some way (say hitting a save button). The UI calls the domain logic tod do its stuff which in tern calls the persistence layer to store the stuff, load some other stuff and this gets returned up the stack until it gets displayed in the UI.

While this is valid information to convey it often isn’t what people think they are conveying. Instead they claim this are dependencies. And maybe they are. But if you want to document your dependencies your diagram should look like this most of the time:

UI -> Domain <- Persistence

The Domain should be the center of your architecture and there for at the center of your dependencies. Everything else, i.e. all the interfaces (in the general sense) should depend on the domain. Not the other way round.

You achieve that by defining interfaces (in the Java sense) inside your domain which then get implemented or used by the UI or the Persistence layer.

If you want you can have those interfaces in seperate layers you can:

UI -> Presentation Interface Persistence Interface <- Persistence Implementation

Just take care that the design of the Presentation Interface and the Persistence Interface is driven by the domain, not by some UI or Persistence technology.

As a side note: If you are using Hibernate / JPA with annotation based mapping you are either violating this design principle, because your persistence technology (JPA) bleeds into the domain logic (annotations on the domain classes) or you have to copy all the data from your entity classes into your domain classes which really is cumbersome and reintroduces the kind of boilerplate code we wanted to get rid of with tools like Hibernate in the first place.

How to resolve that issue is a topic for another day.


The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.


Published at DZone with permission of Jens Schauder , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}