Skip to content

alexpulver/awesome-architecture

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 

Repository files navigation

Awesome Architecture Awesome

This document starts with a list of concepts, mindset and foundations, followed by jobs-to-be-done.

Concepts

  • Application Lifecycle Management (ALM)
  • Architecturally significant requirements criteria: business value/risk, stakeholder concern, quality level, external dependencies, cross-cutting, first-of-a-kind, source of problems on past projects.
  • Architectural decision records (ADRs): Records that support team alignment, document strategic directions for a project or product, and reduce recurring and time-consuming decision-making efforts.
  • Continuous Configuration values often fall into two groups: those that modify operational behavior of an application—such as throttling, limits, connection limits, or logging verbosity—and those that control FAC (Feature Access Control), including feature flags, A/B testing, and user allow/deny lists.
  • Coupling: Coupling describes the independent variability of connected systems, i.e., whether a change in System A has an effect on System B. If it does, A and B are coupled.
  • Coupling facets (video, post): 1/ Technology (Java vs. C++, Kubernetes, PostgreSQL) 2/ Location (IP addresses, DNS) 3/ Data Format (Binary, XML, JSON, protobuf, Avro) 4/ Data Type (int16, int32, string, UTF-8, null, empty) 5/ Semantic (Name, Middlename, ZIP) 6/ Temporal (sync, async) 7/ Interaction Style (messaging, RPC, query, GraphQL) 8/ Conversation (pagination, caching, retries).
  • Declarative provisioning not equal to Declarative language (video, slides)
  • Event-Driven Architecture patterns: 1/ Event Notification 2/ Event-carried State Transfer 3/ Event Sourcing 4/ Command and Query Responsibility Segregation.
  • Feature Flags
  • GitOps: 1/ Declarative 2/ Versioned and Immutable 3/ Pulled Automatically 4/ Continuously Reconciled.
  • Platform: a set of standardized elements that provide value but do not presuppose all problems.
  • SaaS Architecture Fundamentals
  • Software Boundaries or "Fracture Planes": 1/ Business Domain Bounded Context 2/ Regulatory Compliance 3/ Change Cadence 4/ Team Location 5/ Risk 6/ Performance Isolation 7/ Technology 8/ User Personas.
  • Software delivery performance four key metrics: 1/ Cycle Time (Change Lead Time) 2/ Deployment Frequency 3/ Change Failure Rate (CFR) 4/ Mean Time to Recovery (MTTR).
  • Frugal Architecture: 1/ Make Cost a Non-functional Requirement 2/ Systems that Last Align Cost to Business 3/ Architecting is a Series of Trade-offs 4/ Unobserved Systems Lead to Unknown Costs 5/ Cost Aware Architectures Implement Cost Controls 6/ Cost Optimization is Incremental 7/ Unchallenged Success Leads to Assumptions.

Mindset

  • Abstraction in the cloud: a service with higher-level vocabulary that shields from the complexity, security and operations of the underlying implementation (Alex Pulver)
  • A system is only evolvable if you can easily understand it and you can safely change it. (Rebecca Parsons)
  • Cloud automation tools like AWS CDK and Pulumi allow you to implement application’s architecture and logic using the same programming language. (Alex Pulver)
  • Build thoughtfully, and fail fast. (Nadiya Amlani)
  • Don’t look for a great Idea, find a good Problem to solve. (Someone)
  • Feature branching implies a lower bound to the size of a change-set - you can't be smaller than a cohesive feature. (Martin Fowler)
  • Increasing the frequency of integration is an important reason to reduce the size of features. (Martin Fowler)
  • Infrastructure libraries provide compositions, not abstractions, because consumers own security and operations of the underlying implementation. (Alex Pulver)
  • Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again. (Suzanne and James Robertson)
  • To achieve modularity we need to constantly watch our system as it grows and tend it in a more modular direction. Refactoring is the key to achieving this, and refactoring requires high-frequency integration. Modularity and rapid integration thus support each other in a healthy codebase. (Martin Fowler)
  • You won’t be agile by focusing on agile frameworks. Agility requires changing everything we do, beginning with engineering our systems for lower delivery friction. (Bryan Finster)

Foundations

Business and technology alignment

Business metrics

Compliance

Cross-cutting concerns

Frameworks

Landing zone

Organizational culture, structure, and processes

Platform

Product

Product-market fit

Profitable growth

Security

Technology landscape

Working backwards

Jobs-to-be-done

Access control and isolation

API

Authentication and authorization

Configuration

Data lake

Deployment

Development

Encryption

Extensibility

  • Supporting extensibility in SaaS environments (video, slides)

Frontend

Hybrid architecture

Integration patterns

Internet of Things (IoT)

Machine learning

Migrations

Multi-region

Networking

Observability

Operations

Reliability

Sharding and partitioning data

Tenant costs

Tenant management

Testing

About

A collection of awesome things related to architecture

Topics

Resources

License

Stars

Watchers

Forks