Contribution 22

From WikiContent

Revision as of 07:30, 16 May 2008 by Elandre (Talk | contribs)
Jump to: navigation, search

Architects focus is on the boundaries and interfaces

Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, "divide an conquer" has been the mantra for dealing with complex and difficult problems. The challenge is that its easier said than done, at least if your intension is a working system at the end. Hacking something to pieces is seldom constructive.

Therefore the architects focus should be on the boundaries and interfaces when a large problem is partitioned, and later integrated into a working whole. At the end, the systems internal integrity and quality depends on this.

The next thing is, how to do this in practice? First of all there are some old heuristics that might help, if they do not add more to the confusion. Here goes:

Choose the element so they are as independent as possible, or in other words choose elements with low external complexity (simple) interfaces and high internal complexity. Expressed in the language of a software developer strive for high cohesion, low coupling.

In many ways this is the idea behind SOA (Service Oriented Architecture), but experience has shown us that SOA a hard thing to do, especially in situations where there are legacy systems in place, legacy systems that for all practical purposes are huge monolithic monsters.

So the question how to do it in practice is still unanswered. There is though one technique I have used with success, Eric Evan's Context Maps, a technique thoroughly described in his book Domain Driven Design. In short a context map is an informal map of model context extracted from internals of existing systems and the relationships between the contexts. The value provided by a context map is the ability to communicate how an existing software landscape is wired, what belong together, and the interfaces between the contexts.


By Einar Landre

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools