Phil Parker

« All posts

Tweet

 4 September 2014

Architecture 101 + Domain Alignment

This is the outline of a “Lighting talk of two parts” delivered at Agile on the Beach 2014 (#agileotb)

UPDATE: Video is now online This talk starts at 23:30 (but please watch them all!)

Part 1 - Agile 101

Everyone knows that architecture is just “box drawing” so today I’ll just talk about boxes (forget contexts, components, containers, modules, classes, packages etc). This lightning talk is intended to help explore some of the terms used and (controversially!) suggest 5 rules…

Abstraction

This is a term I heard used in maybe 4 out of 5 of the talks I attended today.

Abstraction has two (relatively subtle) different meanings:

(first abstraction subtlety) Elevation == different ‘levels of abstraction’

RULE 1: LEVELS When communicating about Architecture, converse at a single level of abstraction (elevation), and ergo, an appropriate level of granularity.

(second abstraction subtlety) Pattern Identification == something “non-concrete”

RULE 2: EXAMPLES Abstract by example, not speculation.

Encapsulation

• (Not one for the Snapchat generation) but we used to say in Java, don’t expose your privates.

RULE 3:: BOUNDARY Understand your component boundaries (and therefore contracts) at every “level of elevation”.

All of the above (in box terms) defines how to build your boxes but misses an important question….

Part 2 - What’s in the box?

The easiest way to look at this is Rule 2. Q. What sort of examples? A. Business examples.

So when determining what’s in the box think, verticles, verticles, verticles.

A typical architecture diagram shows technological concepts in horizontal layers (we’re really good at this… think front-end and back-end teams or gui, service and dao packages…) and (sometimes) business concepts in vertical “slices”.

RULE 4: ALIGNMENT ??but to what??

I said I’d deliver 5 rules to let’s “right size” RULE 4…

RULE 4 (a): ALIGN your Architecture (portfolio/components) with your Delivery (people)

AND MOST IMPORTANTLY!!!

RULE 4 (b): ALIGN both with your Domain (the reasons why your business changes)

So let’s summarise!

RULE 1: LEVELS When communicating about Architecture, converse at a single level of abstraction (elevation), and ergo, an appropriate level of granularity.

RULE 2: EXAMPLES Abstract by example, not speculation.

RULE 3:: BOUNDARY Understand your component boundaries (and therefore contracts) at every “level of elevation”.

RULE 4 (a): ALIGN your Architecture (portfolio/components) with your Delivery (people)

RULE 4 (b): ALIGN both with your Domain (the reasons why your business changes)

Tweet
comments powered by Disqus