"Software Architecture as a Set of Architectural Design Decisions": "Software architectures have high costs for change, are complex, and erode during evolution. We believe these problems are partially due to knowledge vaporization. Currently, almost all the knowledge and information about the design decisions the architecture is based on are implicitly embedded in the architecture, but lack a first-class representation. Consequently, knowledge about these design decisions disappears into the architecture, which leads to the aforementioned problems. In this paper, a new perspective on software architecture is presented, which views software architecture as a composition of a set of explicit design decisions. This perspective makes architectural design decisions an explicit part of a software architecture. Consequently, knowledge vaporization is reduced, thereby alleviating some of the fundamental problems of software architecture."

Tomas Petricek's writings on the subject:

Architecture of Open-Source Applications (books)

"Don't Call It a Platform": "Habitability, in the broadest sense, describes how nice (or not) the experience is for the people who have to live in a system. ... I make the argument that we ignore habitability at our peril. Those of us in a place to shape the lived experiences of our colleagues have a duty of care to ensure that we take their needs to heart."

"DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together"

"The cloudy layers of modern-day programming"

Platform Engineering Teams Done Right...

The 12-Factor App:
* I. Codebase: One codebase tracked in revision control, many deploys
* II. Dependencies: Explicitly declare and isolate dependencies
* III. Config: Store config in the environment
* IV. Backing services: Treat backing services as attached resources
* V. Build, release, run: Strictly separate build and run stages
* VI. Processes: Execute the app as one or more stateless processes
* VII. Port binding: Export services via port binding
* VIII. Concurrency: Scale out via the process model
* IX. Disposability: Maximize robustness with fast startup and graceful shutdown
* X. Dev/prod parity: Keep development, staging, and production as similar as possible
* XI. Logs: Treat logs as event streams
* XII. Admin processes: Run admin/management tasks as one-off processes

Don't Start with Microservices--Monoliths are your friend

The Nature of Software

Reading

Interesting exemplars/templates/links


Detail Pages:

Last modified 22 January 2024