Architectural descriptions of software-intensive systems often begin with a description of the system’s structural composition. This technical inside-out perspective has made me feel uneasy for quite a while.
In contrast, I like to take an outside-in perspective and begin describing a system by discussing its purpose and the context in which the system will be used in pursuit of this purpose. More concretely, I like to talk about a system’s functions and how work flows through the system when exercising these functions. Working mostly on e-commerce sites, this often means describing user journeys and interaction flows.
And eventually I describe which structural elements collaborate in order to realize these functions. At times, the required mapping of functions and interactions to interacting components and collaborating objects feels tedious and strained.
As I’m learning more about functional programming, I wonder whether describing the architecture of a system built using a functional programming approach will feel more natural? Will the rift between the functional and the structural perspectives diminish as I gain experience with composing functional solutions to non-trivial problems? Or should that read functionally decomposing non-trivial problems?
(As a side note, their work includes the only substantial discussion of form (as distinguished from structure) of software systems I have come across so far.)
But what about the information managed by the system? Wouldn’t we also want to discuss what the system knows (in a casual sense of the word)?
Architecture descriptions (at least most of the ones I’ve seen) tend to discuss relevant data or information models in the context of a system’s structure (i.e. its major building blocks), but that never felt quite right to me. Or is discussing what the systems knows unnecessary because we could include data capture, storage and retrieval in the context of a system’s function?
2014-03-16: Clarified that I used “what the system knows” in a casual sense. This may not have been a good idea — see the comments below.
2014-03-15: Correction: Form describes what the system is in this book, not structure. Also added “major building blocks” to somewhat clarify what I meant with “a system’s structure” in the last paragraph.