Toolbox

Laws

Things that seemed universally true about software architecture. These three laws seem pretty universal and inform many important perspectives for working software architects.

Corollary 1 If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet.

Corollary 2 You can’t do trade-off analysis just once; it’s a continuous process because things change.

We define software architecture in terms beyond structural scaffolding, incorporating principles, characteristics, and so on. Architecture is broader than just the combination of structural elements.

why? examples?

YAGNI

The Essence of Good Design

and relationship with changeability

One Rule to Rule Them All

As developers, we live under a constant barrage of helpful advice, often in the form of rules with cute names. We’re told how to design, how to code, how to deploy, how to monitor: there are systems and rules for everything. How can we keep up? How can we know what’s good advice, and what’s bad?

Over time I’ve come to realize that just about every good piece of advice is actually a special case of something both more general and simpler. So, let me introduce you to the “one rule to rule them all.”

Various (to sort)

ProofOfConcept, Design decision, MVP, TTM, Design principles: SOLID, DRY, KISS, Yagni, Demeter Law, Avoid Premature Optimization, Principle of Least Astonishment and others Keep in mind expected lifespan,

use good judgement

clean code critique That’s why coding is an art in its own right. There’s some good practices and some bad, but if you do not understand the craft, just blindly following good practices will lead you to dogmatic code. And that’s the biggest sin of clean code, it presents absolute dogma, not advice.

Simple Design

Extreme Programming practice; read also “Simple Design” part of the “The Art of Agile Development” book http://www.extremeprogramming.org/rules/simple.html

Simple Thing (?)

https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork

How to use it

Reflection and Improvements