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