The Art of Immutable Architecture: Theory and Practice of Data Management in Distributed Systems (Paperback)

· 제목 : The Art of Immutable Architecture: Theory and Practice of Data Management in Distributed Systems (Paperback) 
· 분류 : 외국도서 > 컴퓨터 > 소프트웨어 개발/엔지니어링 > 일반
· ISBN : 9781484259542
· 쪽수 : 418쪽
· 출판일 : 2020-07-15

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 applications, I sought to build a second Historical Modeling framework for the web. Thus was born Jinaga. This time, I took a more dynamic approach to modeling, expressing queries and predicates directly in JavaScript template functions. Using nested watches, I connected the model with several front-end frameworks, including Knockout, Angular, and React. But the journey into JavaScript did not take me away from rigorous proof. Quite the contrary. I needed to prove theorems of completeness and transitive closure to ensure that the interest set was correctly calculated.

·         Historical facts in a dynamic language

·         Template functions

·         Queries as subscriptions

·         Exists, not exists, and query branching

·         Implicit and explicit interest

·         The return of dependency tracking

·         Progressive web applications