View is thin, dumb and a servant of domain model.. not the other way

I’ve came across this twice lately…

Two independent developers were trying to explain to me why their model is not readable (and maintenable) and doesn’t reflect real domain. Objects were wrongly associated together, and real world classes – were missing and not defined!

The wrong explanation of a dev was:

..because, a user using “admin UI” selects a card text and assigns bunch of NUMBERS (cell ids) it appears on .. No need for “board cell class”

Who cares how an user is using an app.. It should not have any, or minimal impact on how business domain is modelled, even db is designed..
Should it be a browser, a console app, fully dynamic Ajax website or an iPad app.. It’s only how the app looks, and how presents its information about data.

Views change, user preference change. View is a thin layer, only a presenter. Should not drive the design of domain layer.

An app was…

…I was looking at how some game was designed, a board game, and it was missing representation of a BoardCell

In this small OO world:

  • a game has a board
  • a board contains many board cells (hexes)
  • a board cell contains many cards, of which some give special powers

So I was expecting at least this below: (you can copy&run example)..
…But what I found something different


I need real world model, close to business, close to the domain. I want ALL THE REAL CLASSES BE THERE. So I can touch them and work on them.

So, try to cut any class from above code. It will make no sense, as all the objects make sense there. It’s the pure model.

Now, based on this code you CAN start building views. Views may or may not present all the data. May only show final bonus of a player, of a whole board.. who cares.. that is what is view for.. to present, not to define!

Try to imagine your view changes, what then.. would you really want to have model not being a mirror of a real world, and change both: the view, the model … thought so :-) So don’t