Repository #

Repository (a.k.a. data-centered) style is suitable when the central challenge is establishing, augmenting, and maintaining a shared body of information.

Topology #

Example component diagram:

• Component:
  • Repository: persistent central data store representing the current system state.
  • Tools and services: independent components that can read and write the repository, monitor changes, and perform concurrent computations.
• Connector: data CRUD operations and change notifications.

An example of this style is a code editor: many features interact through a shared document buffer.

Pros and cons #

• Pros
  • Maintainability: many features can share the same repository, coordinating through a stable data model.
  • Reliability: centralized data management and persistence mechanisms can simplify durability and recovery.
  • Efficiency: avoids copying large data across many components.
• Cons
  • Complexity: requires governance on data schema, consistency, and concurrency control.
  • Evolvability: schema changes can affect many components; need to handle migrations and versioning carefully.
  • Security, Availability: the repository can become a single point of failure.

Real-world examples #

Code editors #

In editors/IDEs, the text buffer is the shared “source of truth” for the current document state. Many components (rendering, syntax highlighting, search, refactoring, language servers) coordinate by reading from and writing to the buffer rather than calling each other directly. The connectors are buffer operations (insert/delete/replace, range reads) plus change notifications. Editors often adapt the style with indices, incremental parsing, and specialized data structures to meet performance needs on large files.

Further reading:

• VS Code blog: Text Buffer Reimplementation
• Atom API: TextBuffer
• Helix: architecture notes

Android data layer (repositories and data sources) #

Android’s recommended app architecture describes a data layer built around repository classes. In terms of topology, repositories are the “repository components” that other parts of the app depend on, and each repository coordinates one or more data sources (network, database, files). The main connectors are one-shot operations (e.g., fetch/update calls) and change notifications (often represented as reactive streams) that let the rest of the app observe the current state. Compared to the “one big shared repository” version of the style, Android typically uses multiple repositories (one per data type) and emphasizes an explicit source of truth (often a local database) to keep data consistent.

Further reading: Android Developers: Data layer

Git object database #

Git can be viewed as a repository-centered system: many commands (commit, checkout, log, diff, gc, fetch) operate on a shared object database (blobs/trees/commits/tags). Here, the repository is the object store, the components are Git “porcelain” and “plumbing” commands, and the connectors are repository operations over objects and references. The shared storage format enables tooling reuse, but schema/storage evolution must be handled carefully for compatibility and performance.

Further reading:

• The Architecture of Open Source Applications: Git
• Pro Git: Git Internals – Git Objects

Berkeley DB #

Berkeley DB is a reusable repository component embedded into many applications. From a topology perspective, BDB is the repository, embedding applications are the components, and the connectors are library calls for reads/writes and transactions. This arrangement lets many applications reuse the same persistence and concurrency mechanisms without implementing a database from scratch.

Further reading: The Architecture of Open Source Applications: Berkeley DB