Software Architecture as Algorithmic Infrastructure: How Code Becomes Systems

Last Updated June 17, 2026

Software architecture is not only about organizing code. It is algorithmic infrastructure: the structural environment that determines how computational procedures are composed, deployed, coordinated, scaled, secured, observed, changed, and governed.

An algorithm may be clear in isolation, but real systems rarely run as isolated procedures. They run inside architectures made of modules, services, databases, queues, caches, APIs, schedulers, runtimes, data pipelines, deployment environments, observability systems, access controls, and operational practices. Architecture determines how computation moves through these parts.

A weak architecture can turn simple algorithms into fragile systems. A strong architecture can make complex computational systems understandable, testable, reproducible, resilient, and accountable.

This article explains software architecture as the infrastructural layer that turns algorithms into maintainable systems. It examines architecture as a form of computational reasoning: a way of designing boundaries, dependencies, data flow, control flow, failure behavior, governance, and long-term system evolution.

This article explains software architecture as the structural infrastructure of computation. It introduces modules, components, layers, services, packages, boundaries, dependencies, architectural styles, data flow, control flow, deployment topology, state placement, failure containment, scalability, performance, security, observability, testing seams, governance, and system evolution. It emphasizes that architecture is not merely a diagram or folder structure. Architecture determines how algorithmic reasoning becomes operational reality: what can change safely, what can fail independently, what can be tested, what can be audited, and what future maintainers can understand.

Why Software Architecture Matters

Software architecture matters because computational systems grow beyond individual algorithms. They must coordinate data, state, interfaces, execution, storage, failure handling, security, deployment, monitoring, and change over time. Architecture provides the structural discipline for that coordination.

A system can contain excellent algorithms and still fail because its architecture is brittle. The wrong architecture can make testing difficult, scaling expensive, security unclear, data lineage invisible, and change dangerous. The right architecture makes assumptions visible and gives computational work a stable place to evolve.

Architecture is the design of computational dependence. It determines how local reasoning scales into system reasoning.

Back to top ↑

What Software Architecture Is

Software architecture is the high-level structure of a software system: its components, relationships, constraints, responsibilities, runtime organization, deployment shape, data movement, and governing principles. It is not only what the code looks like. It is also how the system behaves, evolves, and fails.

Architecture includes both static and dynamic views. Static architecture shows components and dependencies. Dynamic architecture shows runtime behavior, messages, events, workflows, resource use, scaling, and failure paths.

Architecture is therefore both structure and reasoning. It explains why the system is divided as it is.

Back to top ↑

Architecture as Algorithmic Infrastructure

An algorithm specifies a procedure. Architecture specifies the infrastructure in which procedures live. In a real system, an algorithm may be wrapped in an API, executed by a worker, fed by a data pipeline, configured by environment variables, persisted in a database, monitored by logs, secured by permissions, and deployed through a release process.

This infrastructure changes how the algorithm can be trusted.

Architecture turns algorithms into operational systems. It is the infrastructure of execution, interpretation, and responsibility.

Back to top ↑

Modules, Components, Services, and Layers

Software architecture uses boundaries at different scales. A module may be a file or package. A component may be a larger unit of responsibility. A service may run independently and communicate over a network. A layer groups responsibilities by level of abstraction.

The point is not to create more boxes. The point is to create boundaries that support reasoning.

A useful architecture matches boundaries to responsibility. A boundary without responsibility is ceremony. Responsibility without a boundary becomes confusion.

Back to top ↑

Architectural Styles

An architectural style is a recurring way of organizing computational systems. No style is universally best. Each style makes trade-offs about coupling, deployment, performance, reliability, observability, team organization, and governance.

Architectural style should follow the problem, not fashion.

The architecture is successful when its trade-offs match the system’s actual constraints.

Back to top ↑

Boundaries, Dependencies, and Change

Architecture controls change by controlling dependencies. When a component depends on another component’s private details, change becomes dangerous. When dependencies flow through stable interfaces, internal implementation can evolve more safely.

The goal is not zero dependency. The goal is intentional dependency.

Architecture determines which changes remain local and which changes become system-wide events.

Back to top ↑

Data Flow, Control Flow, and Coordination

Architecture must define how data moves and how work is coordinated. Data flow describes the movement of information. Control flow describes the movement of decision and execution. Coordination determines how components collaborate.

In small systems, control flow may be direct function calls. In larger systems, coordination may involve queues, schedulers, workflows, events, orchestrators, transactions, retries, locks, and distributed traces.

Coordination architecture determines what the system can guarantee about ordering, completion, failure, and recovery.

Back to top ↑

Interfaces, APIs, and Contracts

Architecture depends on interfaces. Components can remain modular only if their boundaries are explicit. APIs, schemas, events, protocols, commands, queries, and file formats define how components communicate.

Contracts are the architecture’s promises.

Architecture fails when contracts are implicit. Systems become more governable when contracts become visible.

Back to top ↑

State, Storage, and Consistency

Architecture must decide where state lives. State may live in memory, databases, caches, queues, files, object stores, sessions, logs, external services, or user devices. These decisions shape consistency, performance, reproducibility, recovery, and accountability.

The placement of state is one of the most consequential architectural choices.

State architecture answers a governance question: where is truth stored, and how can it be reconstructed?

Back to top ↑

Reliability, Fault Tolerance, and Resilience

Reliable systems expect failure. They do not assume that every component, network, dependency, disk, database, queue, or external service will always behave correctly. Architecture defines how systems detect, isolate, recover from, and learn from failure.

Fault tolerance is not only a runtime concern. It is an architectural property.

Resilient architecture makes failure visible, bounded, and recoverable.

Back to top ↑

Scalability, Performance, and Capacity

Architecture shapes performance by deciding where computation runs, how data is accessed, how work is parallelized, where caches are placed, how services communicate, and how resources are allocated. Algorithmic efficiency matters, but architecture determines whether efficient code can operate at the required scale.

Scalability means the system can handle growth in users, data, requests, jobs, events, models, or institutional complexity.

Performance is not only speed. It is the fit between algorithmic cost, architectural structure, workload, and operational constraints.

Back to top ↑

Security, Trust Boundaries, and Permissions

Architecture defines trust boundaries. It decides which components can access data, which services can call other services, where secrets are stored, which users can trigger actions, and which operations require approval. Security is not only a feature. It is structural.

A secure architecture limits authority, validates inputs, isolates risky operations, records consequential changes, and reduces unnecessary access.

Security architecture asks what each part of the system should be allowed to know and do.

Back to top ↑

Observability and Operational Evidence

Architecture determines what evidence a system produces. Logs, metrics, traces, audit records, health checks, profiles, alerts, run manifests, and deployment records help teams understand behavior after execution begins.

Without observability, architecture becomes invisible at the moment it matters most.

Observable architecture preserves the evidence needed for debugging, accountability, and learning.

Back to top ↑

Deployment, Runtime, and Operational Context

Software architecture includes how systems are deployed and operated. A design that looks clean in code may be difficult to deploy, monitor, secure, or recover. Runtime and operational context include containers, virtual machines, cloud services, serverless functions, schedulers, databases, queues, secrets, configuration, release pipelines, and incident response practices.

Architecture connects design-time reasoning to run-time reality.

Operational architecture determines whether a system can be maintained after it is built.

Back to top ↑

Architecture Governance and Evolution

Architecture changes over time. New modules are added. Services split or merge. Schemas evolve. Dependencies change. Platforms move. Data volumes grow. Security expectations increase. Governance keeps architecture from drifting into accidental complexity.

Architecture governance does not mean freezing design. It means making change deliberate and reviewable.

Architecture evolves responsibly when decisions are explicit, consequences are tracked, and boundaries remain legible.

Back to top ↑

Representation Risk

Software architecture carries representation risk because diagrams, repository structures, and service names can make systems appear cleaner than they are. A diagram may show neat boxes while the real system depends on hidden databases, shared caches, undocumented scripts, manual deployments, fragile environment variables, or implicit data contracts.

Architecture representation should reveal important dependencies, not hide them.

The representation of architecture should support judgment. It should show the system people actually depend on, not only the system people wish they had.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

A software architecture can be represented as a graph:

A component can be modeled as a boundary plus implementation:

Architectural coupling can be approximated by dependency density:

Failure propagation can be represented as reachability in a dependency graph:

Architecture quality can be summarized as:

These models show why architecture belongs to computational reasoning. It is the graph of dependence through which algorithms become systems.

Back to top ↑

Python Workflow: Architecture Audit

The Python workflow below creates a dependency-light audit for software architecture as algorithmic infrastructure. It scores boundary clarity, modular cohesion, dependency control, interface discipline, state ownership, failure containment, scalability readiness, security boundaries, observability, and governance readiness. It also analyzes a simple dependency graph.

# architecture_audit.py
# Dependency-light workflow for auditing software architecture as algorithmic infrastructure.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class ArchitectureCase:
    case_name: str
    problem_context: str
    architecture_choice: str
    boundary_clarity: float
    modular_cohesion: float
    dependency_control: float
    interface_discipline: float
    state_ownership: float
    failure_containment: float
    scalability_readiness: float
    security_boundaries: float
    observability: float
    governance_readiness: float


DEPENDENCIES = [
    ("api", "domain"),
    ("domain", "interfaces"),
    ("infrastructure", "interfaces"),
    ("worker", "domain"),
    ("worker", "queue"),
    ("reporting", "domain"),
    ("reporting", "storage"),
    ("api", "auth"),
    ("api", "observability"),
    ("worker", "observability"),
]


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def architecture_quality(case: ArchitectureCase) -> float:
    return clamp(
        100.0 * (
            0.12 * case.boundary_clarity
            + 0.12 * case.modular_cohesion
            + 0.12 * case.dependency_control
            + 0.10 * case.interface_discipline
            + 0.10 * case.state_ownership
            + 0.10 * case.failure_containment
            + 0.08 * case.scalability_readiness
            + 0.10 * case.security_boundaries
            + 0.08 * case.observability
            + 0.08 * case.governance_readiness
        )
    )


def architecture_risk(case: ArchitectureCase) -> float:
    weak_points = [
        1.0 - case.boundary_clarity,
        1.0 - case.modular_cohesion,
        1.0 - case.dependency_control,
        1.0 - case.interface_discipline,
        1.0 - case.state_ownership,
        1.0 - case.failure_containment,
        1.0 - case.security_boundaries,
        1.0 - case.observability,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(quality: float, risk: float) -> str:
    if quality >= 84 and risk <= 20:
        return "strong architecture discipline with clear boundaries, controlled dependencies, observability, security, and governance"
    if quality >= 70 and risk <= 35:
        return "usable architecture discipline with review needs"
    if risk >= 55:
        return "high architecture risk; boundary, dependency, state, failure, security, or observability gaps may be present"
    return "partial architecture discipline; strengthen boundaries, dependency direction, state ownership, or governance"


def build_cases() -> list[ArchitectureCase]:
    return [
        ArchitectureCase(
            case_name="Modular monolith with strong package boundaries",
            problem_context="A knowledge platform keeps one deployable application while separating domain logic, APIs, storage, reporting, and workflow code.",
            architecture_choice="Internal modules with dependency checks, explicit interfaces, shared observability, and architecture decision records.",
            boundary_clarity=0.88,
            modular_cohesion=0.90,
            dependency_control=0.88,
            interface_discipline=0.86,
            state_ownership=0.84,
            failure_containment=0.78,
            scalability_readiness=0.78,
            security_boundaries=0.84,
            observability=0.82,
            governance_readiness=0.88,
        ),
        ArchitectureCase(
            case_name="Event-driven data workflow",
            problem_context="A data system coordinates ingestion, validation, feature generation, reporting, and archival through events.",
            architecture_choice="Versioned event contracts, idempotent consumers, event logs, data lineage, and dead-letter queues.",
            boundary_clarity=0.86,
            modular_cohesion=0.86,
            dependency_control=0.84,
            interface_discipline=0.88,
            state_ownership=0.84,
            failure_containment=0.86,
            scalability_readiness=0.88,
            security_boundaries=0.82,
            observability=0.88,
            governance_readiness=0.88,
        ),
        ArchitectureCase(
            case_name="Model scoring service",
            problem_context="A model is deployed behind an API and used by downstream decision-support workflows.",
            architecture_choice="Versioned model endpoint, model registry, input schema validation, monitoring, human-review boundary, and rollback policy.",
            boundary_clarity=0.88,
            modular_cohesion=0.86,
            dependency_control=0.84,
            interface_discipline=0.90,
            state_ownership=0.84,
            failure_containment=0.84,
            scalability_readiness=0.86,
            security_boundaries=0.88,
            observability=0.90,
            governance_readiness=0.90,
        ),
        ArchitectureCase(
            case_name="Unstructured script collection",
            problem_context="A growing set of scripts shares files, credentials, global state, and manual deployment steps.",
            architecture_choice="Minimal structure, implicit dependencies, inconsistent outputs, and limited observability.",
            boundary_clarity=0.52,
            modular_cohesion=0.58,
            dependency_control=0.50,
            interface_discipline=0.48,
            state_ownership=0.46,
            failure_containment=0.44,
            scalability_readiness=0.42,
            security_boundaries=0.46,
            observability=0.44,
            governance_readiness=0.40,
        ),
    ]


def dependency_summary(edges: list[tuple[str, str]]) -> dict[str, object]:
    nodes = sorted({node for edge in edges for node in edge})
    outgoing = {node: 0 for node in nodes}
    incoming = {node: 0 for node in nodes}
    for source, target in edges:
        outgoing[source] += 1
        incoming[target] += 1

    possible_edges = max(1, len(nodes) * (len(nodes) - 1))
    density = len(edges) / possible_edges

    return {
        "node_count": len(nodes),
        "edge_count": len(edges),
        "dependency_density": round(density, 4),
        "highest_outgoing_dependency": max(outgoing.items(), key=lambda item: item[1]),
        "highest_incoming_dependency": max(incoming.items(), key=lambda item: item[1]),
        "nodes": nodes,
        "interpretation": "Dependency graphs help reveal coupling, impact paths, and architectural concentration."
    }


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        quality = architecture_quality(case)
        risk = architecture_risk(case)
        rows.append({
            **asdict(case),
            "architecture_quality": round(quality, 3),
            "architecture_risk": round(risk, 3),
            "diagnostic": diagnose(quality, risk),
        })
    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_architecture_quality": round(mean(float(row["architecture_quality"]) for row in rows), 3),
        "average_architecture_risk": round(mean(float(row["architecture_risk"]) for row in rows), 3),
        "highest_quality_case": max(rows, key=lambda row: float(row["architecture_quality"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["architecture_risk"]))["case_name"],
        "interpretation": "Architecture quality depends on boundaries, cohesion, dependency discipline, interfaces, state ownership, reliability, scalability, security, observability, and governance."
    }


def main() -> None:
    rows = run_audit()
    summary = summarize(rows)
    graph = dependency_summary(DEPENDENCIES)

    write_csv(TABLES / "software_architecture_audit.csv", rows)
    write_csv(TABLES / "software_architecture_audit_summary.csv", [summary])
    write_json(JSON_DIR / "software_architecture_audit.json", rows)
    write_json(JSON_DIR / "software_architecture_audit_summary.json", summary)
    write_json(JSON_DIR / "dependency_graph_summary.json", graph)

    print("Software architecture audit complete.")
    print(TABLES / "software_architecture_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats software architecture as auditable infrastructure. It evaluates whether components have clear boundaries, dependencies are controlled, state is owned, failures are contained, evidence is preserved, and change is governable.

Back to top ↑

R Workflow: Architecture Risk Summary

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares architecture quality and architecture risk across synthetic cases.

# software_architecture_summary.R
# Base R workflow for summarizing software architecture as algorithmic infrastructure.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

input_path <- file.path(tables_dir, "software_architecture_audit.csv")

if (!file.exists(input_path)) {
  stop(paste("Missing", input_path, "Run the Python workflow first."))
}

data <- read.csv(input_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_architecture_quality = mean(data$architecture_quality),
  average_architecture_risk = mean(data$architecture_risk),
  highest_quality_case = data$case_name[which.max(data$architecture_quality)],
  highest_risk_case = data$case_name[which.max(data$architecture_risk)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_software_architecture_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$architecture_quality,
  data$architecture_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Architecture quality", "Architecture risk")

png(
  file.path(figures_dir, "architecture_quality_vs_risk.png"),
  width = 1400,
  height = 800
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Architecture Quality vs. Architecture Risk"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

png(
  file.path(figures_dir, "architecture_dimensions.png"),
  width = 1400,
  height = 800
)

dimension_means <- colMeans(data[, c(
  "boundary_clarity",
  "modular_cohesion",
  "dependency_control",
  "interface_discipline",
  "state_ownership",
  "failure_containment",
  "scalability_readiness",
  "security_boundaries",
  "observability",
  "governance_readiness"
)]) * 100

barplot(
  dimension_means,
  las = 2,
  ylim = c(0, 100),
  ylab = "Average score",
  main = "Average Software Architecture Evidence by Dimension"
)

grid()
dev.off()

print(summary_table)

This workflow helps compare modular monoliths, event-driven workflows, model scoring services, and unstructured script collections by architectural clarity, dependency discipline, failure containment, security, observability, and governance.

Back to top ↑

GitHub Repository

The companion repository for this article will provide reproducible code, synthetic datasets, workflow documentation, generated outputs, dependency-graph diagnostics, architecture audit examples, and governance artifacts that extend the article into executable examples.

articles/software-architecture-as-algorithmic-infrastructure/
├── python/
│   ├── architecture_audit.py
│   ├── dependency_graph_examples.py
│   ├── modular_boundary_examples.py
│   ├── reliability_pattern_examples.py
│   ├── architecture_governance_examples.py
│   ├── observability_examples.py
│   ├── calculators/
│   │   ├── architecture_quality_calculator.py
│   │   └── dependency_risk_calculator.py
│   └── tests/
├── r/
│   ├── software_architecture_summary.R
│   ├── architecture_risk_visualization.R
│   └── architecture_governance_report.R
├── julia/
│   ├── architecture_graph_examples.jl
│   └── modular_system_examples.jl
├── sql/
│   ├── schema_software_architecture_cases.sql
│   ├── schema_architecture_taxonomy.sql
│   └── software_architecture_queries.sql
├── haskell/
│   ├── ArchitectureGraph.hs
│   ├── ModularBoundary.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── software_architecture_audit.c
├── cpp/
│   └── software_architecture_audit.cpp
├── fortran/
│   └── architecture_quality_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── architecture_dependency_rules.pl
├── racket/
│   └── architecture_graph_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── software-architecture-as-algorithmic-infrastructure.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_software_architecture_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── software_architecture_as_algorithmic_infrastructure_walkthrough.ipynb
├── canvas/
│   ├── canvas_manifest.json
│   ├── canvas_cards.json
│   └── canvas_index.md
└── shared/
    ├── schemas/
    ├── templates/
    ├── taxonomies/
    ├── benchmarks/
    └── governance/

Back to top ↑

A Practical Method for Reviewing Software Architecture

A practical architecture review begins with the question: does this structure make the system easier to understand, test, change, secure, observe, and govern?

Architecture review should make structure visible enough to support judgment before incidents force discovery.

Back to top ↑

Common Pitfalls

A common pitfall is mistaking architecture for a diagram. Another is mistaking more services, more layers, or more abstractions for better design. Good architecture is not the architecture with the most boxes. It is the architecture whose boundaries match the real structure of responsibility, change, data, failure, and governance.

Common pitfalls include:

• diagram-driven design: architecture looks clean on paper but does not match runtime behavior;
• accidental coupling: components appear separate while sharing hidden state or private assumptions;
• premature distribution: services are split before the team can handle distributed complexity;
• layer bypassing: components skip intended boundaries and depend on implementation details;
• shared database overreach: many components mutate the same tables without clear ownership;
• weak failure design: retries, timeouts, rollback, and recovery are not planned;
• observability as afterthought: logs and traces are added only after incidents;
• security bolted on later: permissions and trust boundaries are not structural;
• architecture drift: decisions change gradually without documentation or review;
• governance gap: no one owns components, contracts, dependencies, or deprecation paths.

The remedy is to treat architecture as living infrastructure: documented, tested, observed, reviewed, and refined.

Back to top ↑

Why Architecture Shapes Computational Judgment

Software architecture matters because algorithms become consequential only when they are placed inside systems. Architecture determines where computation runs, how it receives data, how it stores state, how it exposes results, how it handles failure, how it scales, how it is secured, how it is observed, and how it changes over time.

A strong architecture does not eliminate complexity. It organizes complexity so that people can reason about it. It gives algorithms stable boundaries, visible dependencies, governed interfaces, resilient execution paths, and evidence trails. It supports testing, reproducibility, security, accountability, and long-term maintenance.

Software architecture is therefore algorithmic infrastructure. It is the system of boundaries, dependencies, flows, runtimes, storage, and governance that turns abstract procedures into operational computation. To reason responsibly about algorithms, we must reason about the architecture that carries them.

Back to top ↑

Related Articles

• APIs, Interfaces, and Modular Computational Design
• Testing, Verification, and Computational Reliability
• Runtime Systems, Environments, and Computational Context
• Memory, State, and Mutation in Computation
• Metadata, Provenance, and Computational Traceability
• Computational Experiments and Reproducible Workflows
• Training, Testing, and Generalization
• Model Validation, Testing, and Computational Evidence

Further Reading

• Bass, L., Clements, P. and Kazman, R. (2021) Software Architecture in Practice. 4th edn. Boston, MA: Addison-Wesley.
• Brooks, F.P. (1995) The Mythical Man-Month: Essays on Software Engineering. Anniversary edn. Boston, MA: Addison-Wesley.
• Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Chichester: Wiley.
• Evans, E. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston, MA: Addison-Wesley.
• Fielding, R.T. (2000) Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine. Available at: UC Irvine.
• Fowler, M. (2002) Patterns of Enterprise Application Architecture. Boston, MA: Addison-Wesley.
• Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994) Design Patterns: Elements of Reusable Object-Oriented Software. Boston, MA: Addison-Wesley.
• Kleppmann, M. (2017) Designing Data-Intensive Applications. Sebastopol, CA: O’Reilly Media.
• Newman, S. (2021) Building Microservices. 2nd edn. Sebastopol, CA: O’Reilly Media.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058.

References

• Bass, L., Clements, P. and Kazman, R. (2021) Software Architecture in Practice. 4th edn. Boston, MA: Addison-Wesley.
• Brooks, F.P. (1995) The Mythical Man-Month: Essays on Software Engineering. Anniversary edn. Boston, MA: Addison-Wesley.
• Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Chichester: Wiley.
• Evans, E. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston, MA: Addison-Wesley.
• Fielding, R.T. (2000) Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine. Available at: https://ics.uci.edu/~fielding/pubs/dissertation/top.htm.
• Fowler, M. (2002) Patterns of Enterprise Application Architecture. Boston, MA: Addison-Wesley.
• Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994) Design Patterns: Elements of Reusable Object-Oriented Software. Boston, MA: Addison-Wesley.
• Kleppmann, M. (2017) Designing Data-Intensive Applications. Sebastopol, CA: O’Reilly Media.
• Newman, S. (2021) Building Microservices. 2nd edn. Sebastopol, CA: O’Reilly Media.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058.

Back to top ↑