In Relation To

Back to home

From component model failure to layer fetishism

Posted by    |      

Gavin pointed out that he did not get the separation between business logic and UI. Which leads to the question of why are we layering in the first place? I have heard many many bad reasons to justify layering. Actually, this is one of my favorite questions when I give a training. It's always fun to see the people sweating over a justification.

What are the problems layering is trying to solve:

  • separation of concerns
  • easier maintainability
  • loose coupling
  • reusability
  • justifying yet another additional level of management in the organization

So what could be the problems of such static horizontal layers:

  • the distinction between them could be fuzzy and lead to endless hair splitting discussions at the cafeteria
  • they naturally force state conversion and state transfer across layers for the sake of isolation. State conversion and state transfer are hard to solve, slow and lead to duplication and maintainability nightmares: where did my loose coupling go?
  • they have no real purpose half the time but to please the God of Architecture, tens of thousands of empty and meaningless classes are written to fill up layers implementing delegation patterns over delegation patterns.

Horizontal (hence static) layering in the standard sense of it (presentation, service, component, dao) is a notion inherited of the dark days where:

  • the component model was bloated and unusable
  • stateless applications were the golden goal because it scales better

We need a way to define dynamic reusable concerns, interactions between them, avoid unnecessary state copy and duplication, and find more natural boundaries between concerns. A component model could achieve that if it were shared by the presentation, the business and the data access layer technology with no blind butcher axed boundaries.

Now, bare with me a second and imagine that you had at your disposal a lightweight component model, where components could depend on each other in a strongly and decoupled way, where components could interact with each other by sending events, where components could hold state and whose lifecycle would be handled automatically.

A component would describe and implement a business need 

@Component
public class Checkout {

It would depend on other business components 

@Component @Asynchronous @PayByCheque 
public class ChequePaymentProcessor implements PaymentProcessor {

describing the dependency and its requirements with natural adjectives in a loosed coupled and type safe way 

    @In @Asynchronous @PayByCheque PaymentProcessor

It could have declarative behavior 

@Transactional @Component
public class Checkout { ... }

It could notify other business components 

    @In @Notifier @New Event<Order> order;

And other components could listen to those events in a decoupled way 

@Component 
public class AuditAgent {
    public void onOrder(@Observes @New Order order) { ... }
}

Oh, and finally it would be concise (check the previous examples :) )

Of course some components could be more technical than business oriented, some could be more DAO-ish others more Service-ish. But the point is that this component model and the declarative loose coupled type safe way to describe interactions with other components is very flexible and adjusts to your needs. It fits your needs, you have to fit in it.

So what do we have?

  • separation of concern: loose coopling and declarative interations and behaviors
  • easier maintainability: type safety and no state transfer
  • loose coupling: interface / implementation runtime and type safe binding
  • reusability: a component represents a use case, a story of your application
  • justifying yet another additional level of management in the organization: if you really insist, we can find a way

Seam has paved the way of components describing a story shared across all the technologies in my system and Web Beans will bring it the elegant type safe declarative touch of Guice.

Back to top