In a recent job as a consultant I came to several realizations (and I
realize that this may stir up some 'discussion'):
1. The is precious little material to guide an architect in providing
solutions to architectural problems. There is at least some material
that explains how an architect should approach a problem in terms of
how to document it, there is a lot of navel gazing about what
architecture actually is and there is plenty of material that claims
to present architectural solutions, but which are actually solutions
to a very specific set of problems.
2. Design Patterns tend to exist at the level of implementation -
e.g.. the GoF book defines patterns that are aimed at developers using
the C++ family of languages - many of the patterns outlined are not
relevant in languages that have significantly different underlying
metaphors.
3. There are no design patterns that address a higher-level of
abstraction, i.e. one that is independent of both the implementation
language and the problem domain.
So I set about putting together a related set of architectural
patterns which I have started publishing on my blog here:
http://www.jools.net/archives/44.
Apart from the obvious self-promotion going on here, I would be
genuinely interested in hearing other people's views on:
a) Whether or not the idea of a set of architectural patterns at this
level is something worth fleshing out.
b) Is the 'level' here well-defined enough?
c) Has this already been done?
d) Whether or not I managed to hit that level - i.e. are the patterns
sufficiently general as to be applicable to a wide set of problems and
implementation technologies.
e) The patterns themselves and the usefulness/clarity of the
explanations given.
|
