Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Dependencies in a Three Tiered Application

DZone's Guide to

Dependencies in a Three Tiered Application

· Java Zone
Free Resource

Bitbucket is for the code that takes us to Mars, decodes the human genome, or drives your next car. What will your code do? Get started with Bitbucket today, it's free.

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.

 

Bitbucket is the Git solution for professional teams who code with a purpose, not just as a hobby. Get started today, it's free.

Topics:

Published at DZone with permission of Jens Schauder, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}