Dit is deel 1 van een serie van drie artikelen die architectuurprincipes introduceren van een domain driven architectuur.

 Deze serie is oorspronkelijk gepubliceerd in 2001, maar zoals alle artikelen op deze site die niet als blog artikel zijn verschenen in de loop van de jaren aangepast. Deze architectuurprincipes zijn in een groot aantal projecten met succes geïmplementeerd — op verzoek kunnen wij referenties aanleveren.

In dit tweede deel wordt de structuur van het business domein component duidelijk gemaakt. Deel 1 behandelt de basisprincipes. Deel 3 gaat over de service architectuur koppeling.

Inleiding

Nadat de vorige keer een algemene structuur is geschetst van wat door mij genoemd wordt een domein- of business-centered architectuur, is het in dit artikel de bedoeling duidelijker te maken wat dit inhoudt.

Het doel van het domein component, zoals in het vorige artikel geschetst, is een draaiend software systeem dat een exacte replica tracht te zijn van de business.

Dit artikel is de tweede in een reeks van drie. In deel drie zal de architectuur uitgewerkt worden in een schets van een fysieke implementatie die probeert zo duidelijk mogelijk een beeld te geven van wat een mogelijke realisatie van de ideeën in de praktijk zou kunnen zijn. De term die hiervoor gebruikt wordt is die van Service Architectuur, waarin duidelijk wordt dat onder architectuur niet alleen een fysieke, maar ook een logische en conceptuele betekenis moet worden gehecht.

In dit derde deel worden de principes die in de voorgaande delen zijn behandeld uitgewerkt in een simpele voorbeeldimplementatie.

Deel 1 behandelt de basisprincipes. Deel 2 gaat over de business domein component.

Doelstelling

Teneinde de beweringen in de voorgaande artikelen te ondersteunen met voorbeelden uit de praktijk, wil ik in dit artikel een eenvoudige implementatie uitwerken. Deze implementatie heeft tot doel de lezer een helder beeld te geven van wat de uitwerking van de ideeën in de praktijk behelsd, en de pragmatiek van het architectuurmodel te bewijzen. Hier is geen sprake van rocket-science, alleen uitvoerbaar door genieën of bovengemiddeld begaafde ontwikkelaars! Dat zou onder andere één van de vooronderstellingen al onderuit halen, namelijk resultaten op korte termijn.

Models created using the modelling techniques we talk about on this site are extremely scalable. In fact we call them infinitely scalable. This corresponds to the classification in Martin Fowlers Patterns of Enterprise Application Architecture (The Addison-Wesley Signature Series) book of the Domain Model pattern. Maybe it is something readers have overlooked, but the curve for the Domain Model is assumed to be linear.

However there seems to be a price to be paid for this scalability:

1. models will usually grow to be almost impossible to comprehend
2. models will contain more and more redundancy
3. the size of the model will have a negative impact on performance
4. ... and will all of this not lead to a downgrade of scalability since adding new functionality will become difficult?

In this article we will try to explain why we think that, in the context of models endowed with the characteristics of a Domain Model, these problems are not valid or at least much less relevant.

This article is available in English as The Mirrored World.

Software is de spiegelwereld. De buitenwereld is de "gewone" wereld waarin wij leven. In toenemende mate zien we dat, met de groei van het internet en talloze software systemen waarmee we ons omringen en waar we in toenemende mate niet meer zonder kunnen, er sprake begint te zijn van "twee ikken": de ik in de gewone buitenwereld, en ons ik in de binnenwereld, de persoon die wij zijn als we googlen naar onze persoon, de profielen op allerlei forums, de blog aanwezigheid van steeds meer mensen. De virtuele persoon die we in toenemende mate ook zijn.

This article attempts to describe a possible implementation of an architecture process in organisations that strive towards greater agility.

The RACI matrix

Before diving into the architecture process itself, we think about roles and responsibilities in organisations. For this we often employ a matrix that we find helpful: the RACI matrix.

The matrix as shown above shows a possible situation for a specific project or organisational unit. We see that Smith is Responsible, Jackson is Accountable, and some others who are Consulted or Informed.

Various variations on this basic model exist, for more information see the links below this article.

What is the meaning of these terms?

• Responsible - means a person or role with the skills and or expertise to understand and explain, and to peers (other Responsible persons or roles) defend a specific policy or action
• Accountable - means a person or role with the assigned final right to decide, with the mandate and usually the funding to start or stop a certain organisational activity such as a project. Equivalent to an executive responsibility.
• Consulted - means a person or role that is consulted for the activity, because their input is necessary or desirable. The input is in the area of knowledge, skills or expertise, rarely on the executive level.
• Informed - means a person or role who should be informed of the proceedings or decisions taken, but is not directly involved in the process.

We focus in this article on the first two roles, because they are the most interesting with respect to the architecture process. Also we try to give a deeper meaning to the Responsible role, since we think that role has been undervalued in the literature, and we link this role to that of the architect.

Domain Driven Design has been proving to be a powerful technique for designing complex software systems for many years. The publication of the book by Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software marked the start of a period in which this design technique has been named Domain Driven Design explicitly, but in fact it has been a “secret” of master modellers many years before. This article, divided up in several chapters, will introduce a strategy to use DDD for legacy migration.

This article is only available in English.

Introduction

Facets is the label I want to put on a metaphor for designing domain-centric architectures and systems. It has emerged from a growing dissatisfaction with how software engineers have been thinking about the way systems should be designed, and how these systems are supposed to be delivering value to their users.

It refers to the facets of gemstones, each facet reflecting the something of the outside world and adding or augmenting to it from the gem itself. These facets represent the different angles from which we should approach components in the complex systems we build (or maybe: want to build but horribly fail to).

Many articles on this site talk about domain design, and some talk a little about user interface design and other aspects (usually designated under the label "technical components") but I have not yet attempted to clearly describe the overall vision behind these articles, which is both much broader and much deeper than you can read in these articles.

Thoughts often need time to ripen, to learn from experience and grow, and maybe this was what was needed; but the last few weeks these thoughts have been brooding in me and I decided that, ripe enough or not, I should at least make the attempt to externalise them. Do not hesitate to join me in developing these ideas by using the comment system.