Home/ Questions/Q 904039
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T15:59:06+00:00

I’m just getting into how to write a good architecture of a good software

  • 0

I’m just getting into how to write a good architecture of a good software
system, and I’m learning how to separate high level components into Layers.
In this case, I’m trying to use Tiers, so as to model each Layer as a black
box.

There are 4 tiers in my architecture: Presentation, Application Services,
Business Logic, and Domain/Persistence. For the purposes of my question,
we really only need to focus on the Presentation and Application Services.

The Application Services Layer will contain a Service that allows tracking
of a certain event. The Presentation will have several views that should
update dynamically as the tracking model of the events change. Inherently,
it seems that I need a one-way change-propagation mechanism.

Since I’m trying to model these Layers as Tiers, I’d like to restrict communication
between Facade objects for each Tier, and when necessary, allow a Tier
to aggregate an object from one Tier lower, though only known by interface.

I’m programming this application in Java, so the obvious thing to use is
Observable/Observer. However, I don’t like that the update method for the
Observer interface forces you to cast object arguments. I want to work around
this by defining my own interface and class for this mechanism. The problem,
then, is that the Application Logic will depend on an interface from the Presentation
Tier, a certain no-no for this architecture. Is this a sign that I should try
modeling with MVC fore-most and Layer the Model? Or would it be a better idea to
model each of the views with an interface known in the Application Services Layer.
It seems like a bad place to put it, and I’m stuck. Also, I’m using the View-Handler design pattern to handle the multiple views.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Observer/Observable is often not the best approach, especially in Java where you have to derive from Observable thus wasting your single inheritance. It also, as you discuss, causes coupling which is bad when it crosses tiers.

    I would be more inclined to investigate a pure Event model, with the services providing a way to register EventListeners and firing, perhaps, a PropertyChangeEvent when the change occurs.

    The Services layer could then be notifying other services, or notifying the Presentation layer — it doesn’t know and doesn’t care, and only the presentation is coupled to the service by way of registering as a listener.

    • 0