Patterns of domain model

The concept of pattern is a complicated one. When I here the word pattern I remember my history teacher ages ago when he described the difference between Roman and Gothic churches. There is a pattern of with which you can separate these. The pattern is window and door holes. During Roman times the building techniques was more primitive and the arcs were round. The during Gothics the constructing skill developed so that people learned to create narrow and sharp angel arch. These two arch shapes are the patterns.


So pattern is something that is nothing precise but something vague that one can identify.


When we consider Gang Of Four Design Pattern there is actually no domain area pattern at all!


I have tried to find domain model pattern but I have found only a few. Actually I think so that all my business line models are close to patterns.


Here is quite genuine domain pattern. One leading idea on pattern is that one cannot use pattern as such but one have to modify it to suite the current usage of pattern.

As I did already mentioned in previous post I call this “plan – implement” pattern.

The pattern concerns a design and implementation process of designing of repeating events. The idea is to design a repeating base time period like week, month or day as a template and for some period the actual even are created according to this template.

Examples of areas where this ably are for instance: all route transports like buss lines, railway connections, airline route flight, route transfer business on track and ships and also training organization or broadcasting companies.

The basic pattern is the follow ( at least I think so).

Some of the classes like Week and Day can be omitted, but this will give best give you the idea.

Thanks for all the comments to previous post and Tim Lethbridgefor the reference to his book.


3 Responses

  1. As usually wit your posts, I generally agree but have few remaks.

    Patterns are as old as mankind and dressing an inventory of them is illusory. Pattern recognition & reuse is the most usual trick of intelligence.

    Pattern’ description is only vague because we are not used to describe quality requirements; we usually describe functional requirements (see Use Case fe) but we only associate (when done) a few adjectives for adding quality requirements.

    And indeed quality requirements in a vacuum don’t mean anything, they have to be applied on functionnal requirements.

    This applies to all what you have written.

    “plan – implement” is somewhat too generic for naming a pattern; it is the basis embryo to describe “think”

    According to me, patterns get much more attention compared to what it desserves but this fashion may correspond to a decline in thinking capability in the west, I don’t know for sure, but what I mean is that any serious programmer (now an uggly word for most people dreaming to be asap a manager) can’t program without applying patterns. But again, the average quality of the programmer is also declining (being able to make something is now low level and the claim that good IT project manager must not be IT knowledgeable is more and more heards, no surprise that project failures are more and more avoiding by multiplying costs and delays) so that it becomes necessary to program some patterns to this new generation of robot-programmer (unless it is targetting to robot-manager?)

    Last thing, reuse is successful when something reusable is reused at least once. Patterns follow that law. The chance for being reused is to deliver them as white boxes (and possibly using them as grey boxes, ie thru interfaces). This is thus useles to discuss the pro and contra of any proposed pattern (domain or not).

  2. This is an intriguing matter that has bothered me for quite some time. Not that I would be able to even precisely specify the issue, but I do feel that patterns and “related things” is one of the enablers of good information managements. Unfortunately the opposite is also true and wrong implementation of patterns may ruin your enterprise architecture.

    I agree with Claude in that patterns have been here from the very start. I’ve sometimes commented that our current understanding of patters, or classification, originate from Plato and Aristotle who laid out the foundation. Obviously it is a bit semantic quesiton as well, but for me a good real life example of this is Linnaeus’s work of botanic classification.

    My use of patterns is to give guidelines and standards to follow. The abstraction of patterns vary as well as the intended use of them correspondingly. A high level pattern may define that a business transaction is a thing connecting parties and things. On a more detail level a pattern may give a starndar way to efficienly model an organizational structure.

    I feel Tamminen’s pattern is on this detail level, but all levels pontentially bring value. Optimally you would have patterns for all necessary levels you need to manage to keep the integrity and consistency of the levels.

    • Hi

      This all is pure semantics. I am speaking about how to understand and use a concept: pattern.
      Here is a link:

      So for me a pattern is a faint of sketchy idea, a fuzzy description or definition. Pattern for me is very close to concept. Patterns are something fuzzy that repeats itself over some set of object. It is fairly easy in concrete objects. A concept of door is an instance of pattern for me. In my world pattern can be applied but can not be used as such. The latter comes of the fuzzy nature of pattern.

      There can be identified event-type patterns as well. One example could be concept greeting. One can explain or describe the pattern of greeting. The one explain what is essential in it – on other words what is the pattern. One can not teach greeting because it is something in common with a spectrum of different kind of greeting.

      My sincere suggestion is to stop using the term pattern in IT or at least programming context. If I think of patterns on programming here is a list of thing that I come up with: loop-, if- and case-statement. Let’s take for example the loop. There are several different implementation of that in languages for example: for, repeat, while etc. I have been programming with a language: APL that doesn’t contain loop at all!

      Those things that most people in IT today refers as pattern in most cases are implementation of some functionally in a given programming language. In many case these “solutions” are unnecessarily overloaded with generality that is never used and which cases only difficulties to understand the solution and to test it.

      What we really need is an attempt to reach overall complexity minim. This proves to be much more difficult to achieve that is at first sound. Complexity can be divided in two aspects: local and global. Local complexity is evident and easy to understand. The difficulty comes when intrinsic complexity of a system is given and then the local complexity is pushed too low. This will end up with increasing the total complexity sometimes very strongly.

      Here a a very good text from Kevlin Henney with headline and context that I have also considered often.

      -jukka t

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: