Fantasy Footbal as Introductory OO Metaphor

I try to collect good OO Metaphors and this Fantasy Football domain example has just-enough complexity to be useful yet easy to comprehend without having to be a sports fanatic.



Domain Model (buckets of nouns that can also 'Act')
league
commission
commissioner
official
team
owner
manager
general manager
coach
player

Services Model (buckets of verbs associated with domain object actions)
manager.add( player )
manager.fireCoach()
coach.callTimeOut()
player.play()
player.transfer()
owner.transfer( player )
team.play()
team.goTo
official.reviewPlay()


Attribution

I heard this one in October 2006 during a discussion among two of our best Software Architects.

There was some debate as to whether domain objects should have behavior or just be POJOs and whether the service layer should provide all behavior strictly. [See Transaction Script Pattern (all business logic belongs in Service tier)]. 

On the POJO side, it was asserted that most simple VOs can (should) be generated (from Hibernate mappings) ang that DTOs represent a totally unnecessary layer that needs to be coded & maintained and that it was wrong to require that they always be used.  All agreed that DTOs should have no behavior and it would be an antipattern to do so.

Expand upon the definition of Value Object (VO) vs Data Transfer Object (DTO).

Expand upon the concepts of where business logic belongs.  This used to be a major hang-up prior to the 'Service' concept was popular.

Expand upon the concepts of:

• Value objects as data types (rather than intelligent beings with autonomous capabilities)
  
• Should Domain Objects have Behavior?
  
• "Middle Tier as Service Layer" aka "Service Layer as (a) Tier"
  
• Service vs Business Process
• Service vs Function 
• Parent/Child composition hierarchy
  
• Service as bucket of Functions?
• Shared/Reusable Function vs Reusable Service
• Facade
• Domain
• Dependency
• Where does EJB fall in the service vs pojo continuoum?