# configuration/lexicon/data/style.architecture.data.json > 239 lines of code and 0 definitions. Tree: GovLab Context Language: json Layer: domain Canonical: https://banes-lab.com/anatomy/context#file-context-configuration-lexicon-data-style-architecture-data-json Source text: https://banes-lab.com/source/context/configuration/lexicon/data/style.architecture.data.json.txt Listed in [configuration/lexicon/data](https://banes-lab.com/api/source/context/configuration/lexicon/data.md), after [configuration/lexicon/data/security.data.json](https://banes-lab.com/source/context/configuration/lexicon/data/security.data.json.md) and before [configuration/lexicon/data/surface.coordination.data.json](https://banes-lab.com/source/context/configuration/lexicon/data/surface.coordination.data.json.md). ## Contained in - [configuration/lexicon/data](https://banes-lab.com/anatomy/context/folder-context-configuration-lexicon-data.md) ## Source ```json { "category": "codebase-system-architecture-styles", "records": [ { "name": "Central Database Bottleneck", "kind": "anti-pattern", "definition": "Funneling all state through one shared database that becomes the system's scaling bottleneck." }, { "name": "Layer Leakage", "kind": "anti-pattern", "definition": "Letting an inner layer depend on an outer one, violating the direction of the dependency rule." }, { "name": "Layer Skipping", "kind": "anti-pattern", "definition": "Bypassing intermediate layers to call a distant layer directly, undermining the layering." }, { "name": "Monolithic Transform Function", "kind": "anti-pattern", "definition": "Doing all processing in one large transform instead of a series of composable filter stages." }, { "name": "Package by Technical Layer Only", "kind": "anti-pattern", "definition": "Organizing code by technical layer alone, scattering each feature across many packages." }, { "name": "Shared Monolithic Application", "kind": "anti-pattern", "definition": "Building one large shared application instead of composing independently-governed services." }, { "name": "Contract-Governed Service Reuse", "kind": "capability", "definition": "The ability to reuse services across an enterprise through well-defined contracts." }, { "name": "Database-Bottleneck Removal", "kind": "capability", "definition": "The ability to eliminate the shared-database bottleneck by holding state in distributed memory." }, { "name": "Decentralized Ownership", "kind": "capability", "definition": "The ability for separate teams to own, deploy and evolve their services independently." }, { "name": "External System Isolation", "kind": "capability", "definition": "The ability to isolate the core from external systems behind adapter boundaries." }, { "name": "Framework Independence", "kind": "capability", "definition": "The ability to keep business rules independent of any particular framework." }, { "name": "Independent Stage Testing", "kind": "capability", "definition": "The ability to test each filter stage in isolation from the rest of the pipeline." }, { "name": "Infrastructure Independence", "distinctFrom": [ { "id": "lexicon:external-system-isolation", "reason": "Infrastructure independence keeps the core free of the platform it runs on, while external system isolation keeps the systems it calls behind adapters." } ], "kind": "capability", "definition": "The ability to keep the core independent of the infrastructure it runs on." }, { "name": "Locality of Change", "kind": "capability", "definition": "The ability to make a feature's changes in one place because its code is grouped together." }, { "name": "Reorderable Stages", "distinctFrom": [ { "id": "lexicon:independent-stage-testing", "reason": "Reorderable stages can be rearranged or recombined, while independent stage testing exercises each stage alone." } ], "kind": "capability", "definition": "The ability to reorder or recombine independent processing stages." }, { "name": "Structured Code Organization", "kind": "capability", "definition": "The ability to organize code predictably by assigning each responsibility to a layer." }, { "name": "Transactional Simplicity", "kind": "capability", "definition": "The ability to use straightforward local transactions when all state lives in one process." }, { "name": "Adapters", "kind": "mechanism", "definition": "Components that translate between a core's ports and the specific external technologies behind them." }, { "name": "Boundaries", "kind": "constraint", "definition": "The requirement that clear boundaries separate the concentric layers of the system." }, { "name": "Component Boundaries", "kind": "constraint", "definition": "The requirement that each component expose a well-defined boundary and interface." }, { "name": "Dependency Rule", "distinctFrom": [ { "id": "lexicon:boundaries", "reason": "The dependency rule fixes the direction dependencies point, while boundaries are the lines between the layers they cross." }, { "id": "lexicon:use-cases", "reason": "The dependency rule governs direction, while use cases are the application operations held in their own layer." } ], "kind": "constraint", "definition": "The requirement that source-code dependencies point only inward, toward higher-level policy." }, { "name": "Domain Core", "kind": "constraint", "definition": "The requirement that pure domain logic occupy the core, isolated from external concerns." }, { "name": "Layer Separation", "kind": "constraint", "definition": "The requirement that responsibilities be divided into distinct, ordered layers." }, { "name": "Ports", "distinctFrom": [ { "id": "lexicon:domain-core", "reason": "Ports are the interfaces at the edge of the core, while the domain core is the logic those interfaces enclose." } ], "kind": "constraint", "definition": "The requirement that the core define abstract interface points through which all external interaction passes." }, { "name": "Replicated In-Memory State", "kind": "constraint", "definition": "The requirement that application state be kept in replicated in-memory grids rather than a central store." }, { "name": "Unified Deployment Boundary", "kind": "constraint", "definition": "The requirement that the whole application build and deploy as one unit." }, { "name": "Uniform Stage Interface", "kind": "constraint", "definition": "The requirement that every stage share one interface so stages can be composed freely." }, { "name": "Use Cases", "distinctFrom": [ { "id": "lexicon:boundaries", "reason": "Use cases are the operations in the application layer, while boundaries are the lines separating that layer from the others." } ], "kind": "constraint", "definition": "The requirement that application operations be captured as explicit use cases in their own layer." }, { "name": "Anemic Layers", "kind": "quality-attribute", "definition": "The degree to which strict layering produces thin pass-through layers that add indirection without logic." }, { "name": "End-to-End Traceability", "kind": "quality-attribute", "definition": "The degree to which decomposing flow into independent filters makes tracing a request end to end harder." }, { "name": "Feature Cohesion", "kind": "quality-attribute", "definition": "The degree to which all code serving one feature is grouped together rather than scattered by layer." }, { "name": "Independent Scaling", "kind": "quality-attribute", "definition": "The degree to which a single deployable unit prevents scaling parts of the system independently." }, { "name": "Initial Complexity", "kind": "quality-attribute", "definition": "The degree of upfront structural complexity introduced by defining ports and adapters." }, { "name": "Integration Overhead", "kind": "quality-attribute", "definition": "The degree of effort required to wire independently-developed components together." }, { "name": "Operational Simplicity", "kind": "quality-attribute", "definition": "The degree to which a single deployable unit keeps building, deploying, and operating simple." }, { "name": "Shared Technical Concerns", "kind": "quality-attribute", "definition": "The degree to which grouping by feature complicates sharing cross-cutting technical code." }, { "name": "Introduce Port", "kind": "technique", "definition": "A technique for declaring an interface owned by the core that names what it needs from the outside world." }, { "name": "Extract Adapter", "kind": "technique", "definition": "A technique for moving the code that talks to a framework, vendor or protocol into an adapter behind a port." }, { "name": "Move Framework Outward", "kind": "technique", "definition": "A technique for removing framework types and annotations from the core and confining them to adapters." }, { "name": "Repackage by Feature", "kind": "technique", "definition": "A technique for moving the code of one feature from technical-layer folders into one folder of its own." } ] } ```