Intelligent Design:

Application Architecture
of the Human Body


Brittany Storoz || Apps Engineering @ Mozilla

Twitter | @brittanystoroz

Github | brittanystoroz/presentations


We are all literally living and breathing examples of some of the best practices in software development.

"stop making everything so confusing...and ignore my old presentations when I used these analogies."
-- Alex Sexton

Signs of a Healthy Architecture

Healthy architectures produce applications that are:

RELIABLE.    app behaves in an expected manner

  • have no single point of failure
  • autonomic; knows how to handle & recover from errors

Signs of a Healthy Architecture

Healthy architectures produce applications that are:

FLEXIBLE.    easy adaptation to changing circumstances

  • adjust behavior for different environments to work as expected (i.e. various browsers/platforms); responding to external conditions
  • easy to iterate on when developers must change core logic; gracefully accomodates internal changes

Signs of a Healthy Architecture

Healthy architectures produce applications that are:

TESTABLE.    parts can be tested as independent units

  • prevents us from breaking functionality
  • makes it easier to track down and troubleshoot errors when they do occur

Architectural Matters

separation of concerns.


application responsibilities are organized into separate
layers that overlap as little as possible

Architectural Affairs

single responsibility & least knowledge


each module serves a single purpose and

knows as little as possible about other application parts

both support reusability

Architectural Affairs

standard interface for communication.


a consistent and predictable interface allows loosely-coupled modules to interact with one another

"We want a loosely coupled architecture with functionality broken down into independent modules with ideally no inter-module dependencies. Modules speak to the rest of the application when something interesting happens and an intermediate layer interprets and reacts to these messages." -- Addy Osmani

"Decouple app. architecture w/module,facade & mediator patterns. Mods publish msgs, mediator acts as pub/sub mgr & facade handles security"
-- Addy Osmani

Design Patterns to Address Architectural Concerns

The Mediator

  • publish/subscribe pattern that sends & receives messages with a common data model
  • encapsulates how different parts of an application interact
  • central point of control

The Mediator

Central Nervous System (CNS)

  • composed of the brain & spinal cord
  • constantly processing information to excite/inhibit behavior
  • acts as a mediator for all systems to communicate with each other

Design Patterns to Address Architectural Concerns

The Facade

  • abstraction layer between mediator & modules
  • provides a consistent & predictable interface for modules to interact with
  • only part of the application that modules must be aware of (ideally)

The Facade

Peripheral Nervous System (PNS)

  • composed of nerves and glial cells
  • that send & receive chemical transmissions between CNS-body
  • CNS can process this type of message & provide feedback if necessary

Architectural Pros & Cons


  • advantage: modules can broadcast or listen for messages with no concern for the rest of the system; single connection to a mediator rather than multiple connections to each other; if one system is damaged it doesn't necessarily mean others are
  • disadvantage: difficult to gracefully recover from damage to the mediator