I have observed a fundamental pattern in software design – a polarity with what I shall call ‘Task Oriented’ designs and ‘Domain Oriented’ designs. One or the other emphasis may be more appropriate to one kind of application or another.  But usually a balanced approach utilizing a measure of each gives us the best results. 

In the next few posts, I’ll discuss what patterns we can leverage to achieve the right balance, and then well look at how specific .NET components such as Entity Framework can fit in.

Over the last twenty odd years we have watched the emergence of design and development philosophies that describe themselves with names like: object oriented, service oriented, use case driven, or domain driven.  These names point to what their advocates claim is the core motivating force in the design.  These terms give a frame of reference.  They may tell you which artifacts of the design process provide the entry point for design and development.

We can usually guess that if a designer embraces ‘domain driven design’ we can look for a class model (formal or not) that will express the core of the design.  If she speaks of ‘use case driven’ we can look for use cases, stories or scenarios as the primary starting points for the application. I refer to this sort of thing as ‘Task Oriented’ – a more general term to avoid confusion with the terms ‘use case driven’ or ‘service oriented’ that may have a more specific connotation.

I have been impressed with the work of the Iconix group.  Although they have described their method as ‘Use Case Driven’, they treat both tasks and entities as first class citizens in the design from the beginning.  The method revolves around the parallel evolution of a dynamic model and a static model.  The dynamic model consists of use cases and sequence diagrams and other artifacts expressing behavior.  The static model consists of class models and entity relation diagrams that express entities and relationships in the business domain.  Robustness analysis is used as a transitional exercise to unify and evolve the two models and move from abstract representation to concrete designs and code.

Task models and Entity models are the right and left brain of good design.  Taking some inspiration from Iconix, I have come to believe in maintaining a co-evolving domain model and a use case model from the beginning is key.  This applies whether we are doing formal up-front design with modeling tools or if take an agile approach where we use the whiteboard, paper or just code and comments to express an emergent design.

All applications perform tasks and most, if not all, have entities, whether expressed as classes or database objects.  But the emphasis varies.  In the next post we’ll look at some well known architectural patterns and see how they match with a ‘task oriented’ or ‘domain oriented’ approach.

Technorati Tags: