The ICONIX Process in pieces: Domain modelling

Keep refining

Book extract, part IReg Developer regular and Agile Iconoclast Matt Stephens admits to being something of a code fiend since he was 11.

Recently, Matt and his colleague Doug Rosenberg decided to commit the experiences of their youths spent coding software rather then jetting around the park on their BMX bikes to their latest book explaining the best ways for developers to use domain modeling to roll out a solid foundation for Object Oriented Analysis and Design (OOAD).

Their book, Use Case Driven Object Modeling with UML: Theory and Practice, is packed full of illustrative diagrams and helpful exercises for readers to undertake, and features a useful set of top 10 to do lists in each chapter that take you through the construction of a model – in this case for a sample internet bookstore application.

Each chapter opens with a "you are here" diagram of the ICONIX Process that shows in glorious red the area covered by that chapter to keep you orientated.

In this, the first in a series of four excerpts from Use Case Driven Object Modeling with UML: Theory and Practice Matt and Doug introduce domain modeling and challenge you to think in models.

Domain modeling

The following chapter introduces the domain model aspect of the ICONIX Process.

The domain model - you are here...

Imagine if everyone on your team was talking a different language. Let's say you're speaking German, your team mate is speaking French, and someone else is speaking Swahili.

Every time someone speaks, people glean whatever slivers of meaning they can, and then nod as if they've understood perfectly. They then walk away with a completely wrong interpretation of what the speaker was really trying to say.

In virtually all IT projects, the problem of miscommunication is rampant, but it's rarely noticed because everybody thinks they're speaking the same language. They're not. One person says "book review" and some people interpret this as meaning "editorial review" (a review written by an editorial team), whereas others might interpret it as meaning "customer review" (a review written by a customer and posted to the site).

The results can be - and often are - catastrophic, as the system gets developed with everyone interpreting the requirements and the design differently.

Domain modeling aims to solve the problem of miscommunication on projects by establishing a common vocabulary that maps out the problem space. The domain model is a live, collaborative artifact. It is refined and updated throughout the project so it always reflects the current understanding of the problem space.