Part I: Definition I. Why Immutable Architecture? The software that we write today is based on a set of assumptions. I expose these assumptions and reveal how they harm reliability. Woven throughout is a story of a gift card system that fell victim to these assumptions, but eventually broke free through the application of patterns and discipline. · CRUD · Immutability · SOAP and RPC · The Two Generals Problem · Idempotence · Autonomy · Git as a historical system II. The Rules of Immutable Architecture From a set of well-chosen goals, I derive the rules of Immutable Architecture. These rules form the basis of a self-consistent system of reasoning about software behavior. Perhaps the most valuable result of these rules is that they clearly define limitations to an immutable architecture.

I explore these limitations to show the kinds of systems that cannot be modelled historically. Astute readers might notice the similarities with Event Sourcing, so I take a moment to acknowledge them, and to point out the differences. · The nature of historical facts · Partial order · Collaboration · Timeliness · Limitations of immutable architectures · As compared to Event Sourcing III. How to Read a Historical Model With the fundamental rules established, we now need a shared language of Historical Modeling. In this chapter, I provide three. The first two are graphical in nature, and aide in understanding a system and how its components fit together. The third is more rigorous, and provides both a specification and a basis for mathematical proof. · Fact type graphs · Fact instance graphs · Factual modeling language Part II: Application IV.

Location Independence A system modelled historically has the benefit of not being tied to a specific place. This chapter explores the many different ways that information flows from place to place, including REST and microservices. It establishes a vocabulary for where describing information resides, and how it moves between nodes, between services, and between organizations. I weave in the story of building a customer relationship manager to reveal the problems that arose from a hidden assumption of location. · Synchrony · Durability · Time, clocks, and the order of events · The myth of truth · The transaction pipeline · Conflict-Free Replicated Data Types (CRDTs) V. Analysis When I first started using Historical Modeling, it was merely an extension of use-case analysis. While weaving in the story of building a loyalty program, I explain the mathematics behind historical models, including predicate calculus, DeMorgan''s laws, and existential quantifiers. Through reasoned analysis, I uncover edge cases in a proposed system before we write the first line of code.

This helps us identify and mitigate risks, and modify the system requirements to better ensure success. · Use case diagrams · Predecessors as prerequisites · Assertions about history · Logical deduction through predicate calculus · Requirements that we can actually satisfy VI. State Transitions A common tool for analyzing the behavior of software is the state transition diagram. As I was building a supply chain management system, I discovered that this common tool was insufficient to the task. I found that the diagram bifurcated, and it often jumped from one dimension to another. By instead applying Historical Modeling, I brought the system under a much more reasonable paradigm, while still preserving fidelity and answering the questions that people really ask when they inquire as to the state of the system. · Supply chain management · Bifurcating state machines · Many definitions of "state" · Query for work VII. Security Centralization gives us some fantastic tools with relation to security.

When we decentralize, we need to find other ways to achieve the goals of secrecy, authenticity, and trust. Fortunately, a system of writ can be overlaid on top of a Historical Model. This chapter builds on top of digital signatures and symmetric and asymmetric encryption to describe chains and webs of trust. It shows how to find loopholes in a model, and to close them with additional constraints. · Public key cryptography · Shared secrets, shared keys · Role based security and multitenancy · A system of writ VIII. Patterns As I''ve analyzed, designed, and built systems historically, I discovered several patterns that helped me solve common problems. I accumulated these patterns in a notebook that helped me convince myself that a great many software systems can indeed be modelled historically. In this chapter, I document 11 of the most common patterns that I use on almost every model.

You could derive most of these patterns for yourself, but this gives you a head start on creating the most effective models possible. · Ownership · Membership · Mutable Property · Delete/Restore · Service · Identifier Part III: Implementation IX. Query Inverters As I first transitioned from analysis and design to implementation using Historical Models, the first problem to tackle was figuring out the effect of each individual fact. I put this into practice first when designing a mobile game supporting real-time tournaments. I explored the idea of extending dependency tracking into the model, but found that to be inefficient. Then I went back to the mathematics of the axioms, and from there derived a way of computing the affected set. The theory of query inversion has become a core piece of each implementation. · Determinism and dependency · Managing dependencies on behalf of the client · Computing affected sets · Efficient management of many clients X.

SQL Databases Most of my enterprise implementations of Historical Models rely upon a relational database. While telling the story of building a case management system, I describe how predecessors map to foreign keys. I also show how to represent multiple predecessors using associative tables and hash codes. I show how natural keys are preferable to surrogate keys for integration points within the model. · Audit and approval · Foreign keys · Many-to-many predecessors and successors · Select all successors · Where not exists · Indexed views XI. Subscription As I focused on mobile applications, I built the first fully-featured Historical Modeling framework: Correspondence. This is the first system to convert a model specification directly into code. Walking through the simplest Correspondence application, a chat app, we learn how facts themselves can be treated as queues.

By identifying pivots within the model, we can isolate the subsets of the model that each occasionally-connected mobile client has on hand. · Source of facts, not source of truth · Conversations · Identify pivots · Subscriptions and subsets · Factual support for pivots XII. Interest With the renewed interest in JavaScript applicatio.