Enterprise Application Architecture

Enterprise Application Architecture

Purpose

Give an enterprise application's architecture a starting point that is not a diagram: the forces that actually shape these systems, the small number of decisions that determine everything else, and where to find each one.

What makes enterprise applications their own discipline is not size. It is a specific combination: data that outlives the application, many concurrent users who do not know about each other, business rules that are arbitrary and change, and integration with systems nobody controls. Every pattern in this family exists to handle some part of that.

The forces

Business complexity      rules that are arbitrary, interacting, and revised
Data complexity          a schema that outlives the code, and often
                         predates it and is owned by someone else
Concurrency              users editing the same data over minutes, not
                         milliseconds
Consistency              which invariants must hold immediately, and which
                         may hold eventually
Performance              round trips, transaction duration, read/write
                         asymmetry
Availability             what still works when a dependency does not
Integration              systems you cannot change and cannot trust
Organisation             who owns what, who deploys when
Maintainability          the system will be edited by people who did not
                         write it, for a decade
Operability              what happens at 3 a.m., and who can diagnose it

Every decision below trades some of these against others. A design that claims to satisfy all of them has deferred a cost, not avoided one.

The decisions that determine everything else

In a useful discovery order, not a universal dependency chain. Existing constraints often require iteration—for example, concurrency or a fixed schema may reshape aggregate and transaction choices.

1. Where do business rules live?        → domain-logic-organization
2. How does code reach the database?    → data-source-patterns
3. Where is the transaction boundary?   → enterprise-transactions
4. What are the aggregates? (if a
   domain model)                        → domain-logic-organization,
                                          repository-pattern
5. How are concurrent edits handled?    → offline-concurrency-control
6. How are reads served?                → query-objects-and-specifications
7. What crosses each boundary?          → remote-facade-and-dto,
                                          layering-and-boundaries
8. Which boundaries are remote?         → distribution-boundaries

Most architectural pain in enterprise systems traces to one of these being unmade — decided by default rather than by reasoning. Numbers 6 and 5 are the two most often skipped entirely.

Workflow for an unfamiliar system

1. Find the decisions as they were actually made, not as documented: where the rules are, what the repositories return, where @Transactional appears, whether versioning exists, whether reads use the write model. Trace representative call paths and effective transaction configuration; annotation presence alone does not prove a boundary is active. Inspect the project's Java/framework/database versions before handing off version-sensitive advice; this routing skill imposes no Java baseline or upgrade.
2. Identify the application's kind (references/application-types.md) — a batch-heavy integration hub and a transactional web application have different right answers, and applying one's architecture to the other is a common source of accidental complexity.
3. Locate the pain: what is slow, what breaks, what is expensive to change. Use evidence — files touched per feature, query counts, incident history.
4. Route to the specific skill for the decision in question (references/navigating-the-family.md).
5. Record what you learn as decisions with forces, so the architecture becomes re-openable rather than inherited (architecture-decision-making).

Deliver a short map of the relevant decisions: observed code/runtime evidence, inferred force, unresolved constraint, specialist handoff and one check that could confirm or change the choice. If workload or implementation evidence is unavailable, keep the architecture proposal conditional and identify the smallest missing trace, representative use case or owner answer needed.

Decision rules

Starting a new module and the structure is open
        → use the eight decisions as a discovery guide, revisiting them
          as constraints emerge. Do not begin with a
          reference architecture (pattern-selection-and-composition).

An unfamiliar codebase, and the question is "how is this built?"
        → the seven-question description in
          pattern-selection-and-composition, then this family's skills
          for anything that looks wrong.

Something is slow
        → count round trips and transaction duration first
          (architecture-and-performance). Then attribute latency across
          database execution, queues, network, CPU, allocation and contention.

Something is expensive to change
        → count files touched per feature, then look for excessive
          layering, a god class or a missing boundary
          (enterprise-architecture-smells).

Something is wrong under concurrency
        → decide whether the conflict is inside a transaction
          (enterprise-transactions) or across a user's thinking time
          (offline-concurrency-control). They have different answers.

A rewrite is being proposed
        → architecture-refactoring-paths for a pattern change;
          legacy-enterprise-modernization for a system-level programme.
          The rewrite itself is almost never the cheapest option.

A pattern name is being used as a justification
        → ask for the force it answers
          (architecture-decision-making).

Rules

• Enterprise architecture is decided by forces, not by fashion. A pattern is the output of reasoning about a problem; a design that starts from a pattern name is a preference being defended.
• Data often outlives an application and may predate it. Destructive schema/data semantics can be highly irreversible, while additive schemas can evolve safely; classify reversibility instead of ranking every schema decision as the hardest (architecture-decision-making).
• Different modules of one application legitimately have different architectures. A pricing engine and an admin CRUD screen have different forces; forcing one structure onto both is a major source of accidental complexity.
• Reads and writes can have different requirements. Separate models/projections when measured query shape or invariant needs justify synchronization, mapping and consistency cost (query-objects-and-specifications).
• Layers and tiers have different costs. Source boundaries can still impose widespread API and build migration; a network adds partial failure and operations. Process boundaries are expensive but reversible through consolidation or strangling (distribution-boundaries).
• Frameworks implement many of these patterns already. Knowing which — and what their versions actually guarantee — prevents both rebuilding them and relying on guarantees nobody makes (patterns-and-modern-frameworks).
• The cost of an architecture is paid in change. Judge a design by what a typical feature costs, and measure that from history rather than from intuition.
• Most enterprise systems are not new. Assume you are modifying something in production, and prefer incremental paths with a shippable step over a target-state redesign (architecture-refactoring-paths).

References

• Kinds of enterprise application — transactional, workflow, data-intensive, integration, reporting, batch and event-driven systems: the forces that dominate each, the architectural answers that follow, and how a system that is several of these at once should be split. Read when the system's character is unclear or when one architecture is being applied uniformly.
• Navigating this family — the full map of skills in this family, organised by the question they answer, with the symptom that should send you to each and the boundaries between neighbours. Read when locating a decision, or when something is wrong and it is not clear which discipline owns it.