Antifragile Software
$20.00
Minimum price
$27.99
Suggested price
Last updated on 2016-02-08
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!
About the Author
Table 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
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
