Zen of Architecture

 I attended the talk by Juval Lowy at SVCC. He had a very good argument about why functional decoposition is bad. Here is how the logic goes.

Suppose the customer wants function A, B, C. The original design might be:

You might say this is not so good, since the client has to know A, B and C. How about the design below, where the client needs to know only A: 

This sounds like a better design. However, since A needs to call B and C. What you are acutally getting is:


A ended up beling bloated since it has to carry the parameters to call B and C. It can be worse, if you addeing in the error handling and transactions, what you are really end up is this:


Noticed that B, and C is even more bloated than A. B and C has to inform A what to do if there is an error. 

The good design should be layered approach where the upper layer only needs to know one layer down, and it has to be resilient to change:


The good design use those layers of abstraction (the image is not clear, but you get the idea):

  1. client
  2. business logic
  3. resource access
  4. resource

If you can clearly defined this, you have a solid footing on your project. 


blog comments powered by Disqus