Craig Gjerdingen

Chapter 1: Layering

Most common technique to break apart a complicated software system. Layers is the cake analogy for software. Each layer rests on a lower layer. Higher layers use services of the lower layers. Lower layers are unaware of the higher. Layers hide layers beneath them.

Benefits of Layers

• Allows you to understand a layer as a coherent whole, indepentant of others
  
• Layers are substitutable with altenative implementations
  
• Layers provide good boundries for standardization
  
• Layers minimize dependancies between them
  
• Layers promote reuse by higher layers
  

Downside of Layers

• Layer encapsulation misses some things
  
• Extra layers harm performance
  

These make for some tough choices.

Evolution of Layers in Enterprise Applications

Domain logic: business rules, validation, calculations, and the like created the need for layers. Object Oriented languages allow for this. Creaing UI, domain logic, and data source layers. The web and java re-enforced that layers could run on various machines, and largely psuhed the domain logic of the client.

The Three Priciple Layers

• presentation - handling interactions between the user and the software
  
• domain - the work the application needs to do for the domain
  
• data source - logic communicating with other systems that carry out tasks (databases - persist data)
  

Note: Alistair Cockburn presents a different model - the Hexagonal Architecture. (core surrounded by interfaces to externals)
How to separate the layers in the cake model depends on how complicated the applicaton is.

• Layers
  
  
  • Classes
    
    
    • Packages
      
    
    
  
  

Layers will help you enforce dependancies. Domain logic can be difficult to recognize.

Choosing Where to Run Your Layers

Dividing a system into separate pieces helps reduce coupling. Even if they all run on one machine. Usually your chouce is between ease of maintenance and responsiveness.

Data almost always runs on a server, unless a duplicate is localized for mobility.

Interfaces requirements usually dictate the UI location. Generally Web if you can, Rich if you must. But people are quickly finding ways to do things on web interfaces that this will likely become a non-question in a few years.

Chapter 2: Organizing Domain Logic

Simple logic doesn't require decomposition and can be done in a "Transaction Script". But complex logic is where objects come in, and handle this problem with a "Domain Model", primarily around the nouns of the domain. Logic for handling calculations and validations are placed in the model. Each object in this model forwards part of the behavior to another until a strategy object creates the results.

Adding new logic, increasing complexity, and the Domain Model will stay well-organized. Complex logic will increase the complexity of your data mapping however. The Domain Model works with the "Data Mapper"

Another option is the "Table Model", it is designed to work with the "Record Set". It organizes domain logic around the tables. But limits flexiblity in OO handling in your applicaton.

Making a Choice

Depends on how complex your domain is. Others hit the wall of demished productivity as complexity rises. Domain Model however doesn't. Once the decission is made it is hard to change. The chouce need not be exclusive either.

Service Layer

Splitting the domain logic in two. "Service Layer" over a "Domain Model" or "Table Model". This provides a clear API and place to contain logic of tansactions and security. Behavior can be weighted as needed between the Service Layer and the Domain Model. Models with the weight split tend to be use-case controllers. Fowler recommends very thin facade Service Layers if they are used at all.