Josef Blake write an article at Spotify about when to write Architecture Decision Records. Short summary: “Almost always!”.
Embarc has a set of cheat sheets (in German) for Software Architecture.
Simon Brown writes about an architecturally-evident coding style. He proposes to structure the components (what Eric Evans calls modules in Domain-Driven Design) along the architecture: In his example, he prefers functional components (parts of the domain) over a layer-style separation of the various program parts.
He concludes with:
The thinking [here] behind creating a micro-services architecture is essentially the same […]
Which seems a reasonable approach. He notes that this way of architecture design does not apply everywhere, of course. He notes the example of writing unit tests with mocks if the whole component only exposes a domain-layer interface.
I tend to agree with this design, as I like putting the domain as much into focus as possible. It might be a valid approach even to consider parts of the technical solution (i.e. persistence) as part of the domain. Still, it seems valid to cut a larger application along domains, if only to keep the various components small and isolated.
Self-Contained Systems are a software-architecture pattern, described on https://scs-architecture.org/. They are similar to micro services, but include a UI. They are full systems with everything, they do not depend on other things. They represent a single, vertical slice through the overall system.
One advantage, according to Eberhard Wolff as he describes on his video cast, is that a functional requirement can be solved completely within this system. You (usually) don’t have to cross developer teams when you change things; API may turn to be internal APIs if they are not required externally, and may be easier to manage.
What’s it mean to be a Software Engineer? Or, for that matter, a Software Architect?
Brian Webb gives a possible answer on the title distinction, classifying programmers, engineers and architects. The separation in these three groups might seem useful; more investigation necessary, as usual.
Alistair Cockburn wrote a fascinating article already back in 1999 titled “Characterizing people as non-linear, first-order components in software development”, which is still available through web.archive.org. This is a full-scale scientific paper, so get ready for some reading.
In essence, his message is that people are more important than processes:
The fundamental characteristics of “people” have a first-order effect on software development, not a lower-order effect.
He lists four characteristics of people that are relevant to software development:
1. People are communicating beings, doing best face-to-face, in person, with real-time question and answer.
2. People have trouble acting consistently over time.
3. People are highly variable, varying from day to day and place to place.
4. People generally want to be good citizens, are good at looking around, taking initiative, and doing “whatever is needed” to get the project to work.