Bundles
About the Book
For notifications on the latest updates to the book, please follow @russmiles on Twitter.
There's no reason to have an agile process if your software can't keep pace.
This book is a collection of patterns that you can apply to build software that thrives on change and the disorder it brings.
This book is broken into three books that deal with the key challenge of software development today, namely how your software adapts to keep pace with the speed of innovation.
This is currently an Alpha version of the book. It is under active development right now. Upgrades until the book is completed will of course be free!
Read more Read less
-
Feedback
Share this book
Copy embed codeTable of Contents
-
Preface
- Grabbing the Code
- Option 1: Browse the code on GitHub
- Option 2: Download the Code as Zip Files
- About The Author
- Acknowledgements
-
Introduction
- What this book is NOT about
- Philosophical Underpinnings
- Axioms
- What are we really dealing with, then?
- A Nod Towards Over-Production
- Book I - The Philosophy of Change in Software
-
The Parable of The Elephant in the Standup
- Grief, Anger, Disbelief…
- …Guilt…
- The Elephant in the Standup
- Everybody Lies
- Lie 1: It’s a Big Change really…
- Lie 2: The Extended-Holiday of ‘Refactoring’
- Refactoring should be Quick, Easy and Constant
- Lie 3: Sorry, you’re in Technical Debt…
- Technical Debt is for real
- The Elephant in the Standup is not Technical Debt, nor Refactoring
-
Software Architecture is Philosophy
- What is Software Architecture and Design?
- What is Philosophy?
- Software Architecture Abides
- Plato and the Waterfall
- Agility and Fortuna
- Architecture needs to embrace Fortuna
- Stressors on Software
-
Antifragility in Software
- Change, Adaption and Anti-fragility
- The Change Stressor and the Adaption Response
- Defining Antifragile Software Systems
- The Need for Antifragility in Software: Enabling Innovation
- Emergence and Antifragility
- Antifragility is in the Relationships
- Love is Antifragile, an interlude
- Relationships between Parts are the Key
-
Simplicity in Software, Defined
- Simplicity is Objective
- The Simplicity Continuum
- Essential & Accidental Complexity
- Why do we introduce accidental complexity?
- Simple Architecture & Design?
-
Microservice-based Architectures for Antifragility & Simplicity
- Embracing Change with Microservices
- Embracing or even Thriving on Change in the Links between Microservices
- Lies, Damned Lies, and Lies about Microservices
-
The Payback: Speed of Innovation
- What is innovation?
- Enabling Innovation
- Technical Innovation Stressors
- On the Origin of Services…
- Antifragile Systems of Microservices are an Engine for Innovation
- Remember & Apply
- Book II - Architecture, Design & Implementation for Antifragility
-
Skin in the Game
- Ethics: Do It, Risk It
- Show, Share, Make Mistakes, Learn and Improve
- On Being Critical
-
Fear, Loathing & Promise in Uncertainty-Ville
- Idea 1: An Open Cloud Index
- Phone, Or Have a Drink with, A Friend
- Ubiquitous Language & Domain Objects?
- The Ills of the Layered Architecture
- The Domain Objects at the Centre of the Universe Anti-Pattern
- Noone wants to change the Domain Objects…
- Promiscous and Incorrect Domain Objects and the Ripple Effect
- Not the Things, the Things that happen
- Events, a Better Ubiquitous Language
- Past, Unchangeable Facts
- Understanding Events - 90% Accountant, 10% Rock Star
- Event Streams
- Comprehending Event Streams with Projections & Aggregates
- Answering the Question with Views
- Fast and Slow Flows
- Lambdas!?
- What no REST yet?
- Software Antifragility patterns with Stressors
-
Time … to Build
- The Problem of Belonging to Tomorrow
- Reducing the fear of Big Decisions
-
Eating an Elephant with the Life Preserver
- A Tale of Three Teams
- Back to “Skin in the Game”
- What is the right approach to building a system?
- The Process and Tool: The Life Preserver
- Doing O.R.E.: Organise, Reduce & Encapsulate
- The Life Preserver Process: Asking and Answering Questions
- Just Enough Design
- Where does my component go?
- What should my component do?
- Group Together that Change Together
- When should I split my component?
- Discover the Domain
- How should my Components Communicate? Design Events
- How should my Events be transmitted? Design Dispatch
- How should my Events be Encoded? Design Payload
- Thinking Stressors
- Creating Stressors
- Consider Circuit Breakers
- Consider Bulkheads
- 12-Factor Services?
- Consider Technologies Early
- Bounded Contexts, Boundaries & Fracture Lines with Tectonic Plates
- What ‘could’ change
- Naive is ok, at first
- Having a Conversation about Change
- Seeing Inter-Plate and -Component Communication
- Friction at the Fault Lines
- Focus on where the Friction is Greatest
- Testing your Inter-Plate Change Coupling
- The Dangers of Inappropriate Inter-Plate Intimacy
- Flows across the Life Preserver
- Continuous Refinement: Emergent Design
- Scaling Life Preservers
- Big Payback: Objectivitity
-
ManifestNO for Antifragile Software
- Change and Ossification
- Evil Manifestos of Years Past
- Why a Manifesto at all?
- Dodging the Bullet
- Why Microservices are not just SOA
- Remember & Apply
- Suggested Further Reading
Read More Read Less
About the Author
Russ Miles
Russ Miles is CTO at Simplicity Itself where he works with his clients to help deliver simple and valuable software and change.
Russ' experience covers almost every facet of software delivery having worked across many different domains including Financial Services, Publishing, Defence, Insurance and Search.
Russ helps to change all facets of the software delivery process in order to remove unnecessary and costly complexity in everything from developer skills and practices, through applying the right processes for the job at hand, to ensuring that the right change is delivered, be it through software or otherwise.
Passionate about open source software, Russ worked with SpringSource prior to the company's acquisition by VMware, leading the Spring Extensions project and helping international clients to simplify their software by effectively applying the Spring portfolio of projects.
Read more Read less