Modern

Web
- Reactive Manifesto
- Self-Contained Systems (SCS)
  - Resource-oriented Client Architecture (ROCA)
  - Versus Micro-services
- Overambitious API Gateways : anti-pattern per Thoughtworks
- Microservices by Martin Fowler
Books
- Domain-driven Design by Eric Evans
  - Notes here: Domain-Driven Design Book Club Notes
- Building Microservices by Sam Newman
  - Notes here: Building Microservices
- Michael Nygard
Trainings
- Notes from training here: Architecture without an End State with Michael Nygard

Classics

On the Criteria to be used in Decomposing Systems into Modules, Parnas (CMU), ACM, Dec 1972
- Simplifying change as a critical criterion for modularizing software.
- Using "Information Hiding" as the criteria for modularization bodes better to Requirements Changes than "Flowchart-based componentization" i.e., conventional "Functional decomposition".
  - Using libraries to share common encapsulated modules.
- Additional modularization best practices
  - Data structures are not shared/passed outside of the module.
  - The routine and its factory are encapsulated within the module.
  - Encapsulate "formats of control blocks" - i.e., API interfaces.
  - Modules should not rely on sequencing of operations.
- Clean Decomposition is independent of Hierarchical structure
  - Lower-levels can be reused independently
  - Higher-levels are simplified by using lower-levels
Using tool abstractions to compose systems, Garlan, Kaiser, Notkin (CMU/Columbia/UofW), IEEE, 1992
- Managing complexity and supporting evolution are fundamental problems with large-scale systems
- Data abstraction allows easier change in design decisions about the representation of data structures, while tool abstraction allows easier change in system functions.
- Using event-driven integration to implement functional composition on top of data-abstraction-based modularization.
  - Spreadsheets as an ideal example of this - with additive equations as event-driven control of function - orthogonal to the underlying data.
A Note on Distributed Computing, Waldo, et al, IEEE, 1994
- Can't have a fault-tolerant system when remote calls are made as local calls.
Decoupling Change from Design, VanHilst and Notkin (UofW), ACM, 1996
- Making a change can be expensive, even if limited to a single module - as modules themselves can be complex and large.
- Recursively decomposing using Parnas' techniques is not easy or appropriate.
- Decomposing modules around smaller design decisions - encoding one design choice per "submodule".
  - Example design decisions: data type, algorithm, remote or local procedure calling.
  - All design choices are considered equally likely to change.
  - Using C++ template classes
    - Decision not pre-determined by developer.
- Sub-modularize modules to achieve a fine-grained separation of concerns.
- Using submodules, the choice of high level modularization could itself be changed without having to rewrite large amounts of code.
Modularity for the Modern World, Mary Shaw (CMU), ACM, March 2011
- Why Modularize?
  - Intellectual control - cognitive independence.
  - Segmentation of work - distribution of responsibilities.
  - Evolution - localize changes, substitutions, composition, keep up with marketplace.
- Service-oriented architecture