Software
architecture vs code

I presented two talks last week with the title "Software architecture vs
code" - first as the opening keynote for the inaugural Software
Design and Development conference and also the next day as a regular
conference session at GOTO
Chicago. Videos from both should be available at some point and the
slides are available now. The talk itself seems to polarise people, with
responses ranging from Without
a doubt, Simon delivered one of the best keynotes I have seen. I got a lot from
it, with plenty ‘food for thought‘ moments. through to "hmmm, meh".

Separating software architecture from code

The basic premise of the talk is that the architecture and code of a software
system never quite match up. The traditional way to communicate the architecture
of a software system is with diagrams based upon a number of views ... a logical
view, a functional view, a module view, a physical view, etc, etc. Philippe
Kruchten‘s 4+1
model is an example often cited as a starting point for such approaches.
I‘ve followed these approaches in the past myself and, although I can get my
head around them, I don‘t find them an optimal way to describe a software
system. The "why?" has taken me a while to figure out, but the thing I dislike
is the way in which you get an artificial separation between the
architecture-related views (logical, module, functional, etc) and the
code-related views (implementation, design, etc). I don‘t like treating the
architecture and the code as two separate things, but this seems to be the
starting point for many of the ways in which software systems are
communicated/documented. If you want a good example of this, take a look at the
first chapter of "Software
Architecture in Practice" where it describes the relationship between
modules, components, and component instances. It makes my head hurt.

The model-code gap

This difference between the architecture and code views is also exaggerated
by what George Fairbanks calls the "model-code gap" in his book titled "Just
Enough Software Architecture" (highly recommended reading, by the way).
George basically says that your architecture models will include abstract
concepts (e.g. components, services, modules, etc) but the code usually doesn‘t
reflect this. This matches my own experience of helping people communicate their
software systems ... people will usually draw components or services, but the
actual implementation is a bunch of classes sitting inside a traditional layered
architecture. Actually, if I‘m being honest, this matches my own experience of
building software myself because I‘ve done the same thing! :-)

The intersection of software architecture and code

My approach to all of this is to ensure that the architecture and code views
of a software system are one and the same thing, albeit from different levels of
abstraction. In other words, my primary focus when describing a software system
is the static structure, which ranges from code (classes) right up through
components and containers. I model this with my C4
approach, which recognises that software developers are the primary
stakeholders in software architecture. Other views of the software system
(deployment, infrastructure, etc) slot into place really easily when you
understand the static structure.

To put this all very simply, your code should reflect the architecture
diagrams that you draw. If your diagrams include abstract concepts such as
components, your code should reflect this. If the diagrams and code don‘t line
up, you have to question the value of the diagrams because they‘re creating a
fantasy and there‘s little point in referring to them.

Challenging the traditional layered approach

This deserves a separate blog post, but something I also mentioned during the
talk was that teams should challenge the traditional layered architecture and
the way that we structure our codebase. One way to achieve a nice mapping
between architecture and code is to ensure that your code reflects the abstract
concepts shown on your architecture diagrams, which can be achieved by writing
components rather than classes in layers. Another side-effect of changing
the organisation of the code is less test-induced
design damage. The key question to ask here is whether layers are
architecturally significant building blocks or merely an implementation detail,
which should be wrapped up inside of (e.g.) components. As I said, this needs a
separate blog post.

Thoughts?

As I said, the
slides are here. Aligning the architecture and the code raises a whole bunch
of interesting questions but provides some enormous benefits for a software
development team. A clean mapping between diagrams and code makes a software
system easy to explain, the impact of change becomes easier to understand and
architectural refactorings can seem much less daunting if you know what you have
and where you want to get to. I‘m interested in your thoughts on things like the
following:

• Aligning the architecture and code - is this something you do. If so, how?
  If not, why not?


• Is your codebase more than just a bunch of classes in layers? Do you
  follow what George Fairbanks calls an "architecturally-evident coding style"?
  If yes, how? If not, why not?


• If you have any architecture documentation (e.g. diagrams), is it useful?
  If not, why not?

Convincing people to structure the code underlying their monolithic systems
as a bunch of collaborating components seems to be a hard pill to swallow, yet
micro-service architectures are going to push people to reconsider how they
structure a software system, so I think this discussion is worth having.
Thoughts?

source: http://www.codingthearchitecture.com/2014/05/29/software_architecture_vs_code.html

Software architecture vs code,布布扣,bubuko.com