The structure of typical enterprise projects has traditionally been a three-tier architecture. Three-tiers means three technically motivated layers, namely the presentation, business, and data layer. That being said, the project is organized horizontally, with three sub-modules, or packages, respectively.

The idea is to separate concerns from the data layer, from the business layer, and both of them from the presentation layers, as well. Functionality on a lower layer can therefore not have any dependencies on a higher layer, only the other way around. The business layer cannot use functionality of the presentation layer, only vice versa. The same is true for the data layer not depending on the business layer.

Each technically motivated layer or module has its own internal dependencies, that cannot be used from the outside as well. For example, only the data layer would be able to use the database, no direct invocations from the business layer would be possible.

Another motivation is to be able to swap implementation details without impacting other layers. If the database technology would be changed in favor of another, that would in theory not affect the other two layers, since the data layer encapsulates these details. The same is true if the presentation technology changes. In fact, even several presentation layers can be developed with all of them using the same business layer components, at least if the layers are organized as separate modules.

We have seen heated discussions, mostly from high-level architects, about the necessity of organizing and separating responsibilities by technical concerns. However, there are some drawbacks from this approach.