# Repository Architecture The Life Enterprise System (LES) uses a multi-repository architecture on GitHub. This page describes the full repository structure, the rationale for the design, the naming conventions, and the universal folder structure that applies to every repository. The multi-repository architecture was adopted as a formal project decision (Decision 7). The repository naming convention (Decision 19), the repository count (Decision 20), and the universal folder structure (Decisions 33 and 35) were each confirmed as separate formal decisions. *** ### GitHub Account All LES repositories are held under a single GitHub account: **Account:** [github.com/NikiDigitals](https://github.com/NikiDigitals) All repositories are under the NikiDigitals personal account (Decision 12). An organisation account is not used at this stage. *** ### Repository List | Repository | Purpose | Visibility | | --------------- | ----------------------------------------------------------------------------- | ---------- | | `NikiDigitals` | GitHub profile README — NikiDigitals identity and portfolio table | Public | | `LES-Master` | Master: documentation, architecture, governance, decisions, research, journal | Public | | `LES-INFRA` | Azure Infrastructure as Code — all environments | Private | | `LES-PORT` | NikiDigitals website — documentation, content, future custom build | Private | | `LES-API` | Central API gateway layer | Private | | `LES-CORE` | Shared libraries and common utilities | Private | | `LES-FIN` | Finance & Wealth Management | Private | | `LES-EDU` | Education & Knowledge | Private | | `LES-PRJ` | Projects & Goals | Private | | `LES-KNW` | Knowledge Base | Private | | `LES-HLT` | Health & Performance | Private | | `LES-REL` | Relationships & Network | Private | | `LES-OPS` | Daily Operations | Private | | `LES-INT` | Intelligence & Analytics | Private | | `LES-AGT` | AI Agent Orchestration | Private | | `LES-SEC` | Security, GRC & Compliance | Private | | `LES-DASH` | Dashboard — Power BI (Phase 1–2), custom React (Phase 3+) | Private | | `LES-demo-data` | Synthetic data generation for the demo environment | Private | **Total:** 18 repositories (Decision 20). **Visibility policy:** `NikiDigitals` and `LES-Master` are public from inception — they are the public face of the project on GitHub. All other repositories remain private until their content reaches a standard suitable for a technical audience. *** ### Rationale for Multi-Repository Architecture A monorepo — a single repository containing all code and documentation — would be simpler to manage in the short term. The multi-repository architecture was chosen for the following reasons: **Separation of concerns.** Each module has a distinct domain, data model, and development lifecycle. Separating them into individual repositories enforces clean boundaries and prevents accidental coupling. **Granular access control.** Private repositories can be made public independently as they reach a presentable standard. A monorepo is either all public or all private. **Portfolio clarity.** A recruiter or technical evaluator viewing the GitHub profile sees a structured list of purpose-built repositories, each with its own README and status. This communicates architectural thinking that a monorepo does not. **Scalability.** If LES were ever to scale to a deployable product (an option that the architecture preserves — Decision 14), the multi-repository structure supports team separation by domain without restructuring. *** ### Naming Convention All LES repositories follow the pattern `LES-[UPPERCASE]`, where the suffix is a short, uppercase identifier for the domain or function (Decision 19). Infrastructure, shared, and cross-cutting repositories use descriptive identifiers: `LES-INFRA`, `LES-API`, `LES-CORE`, `LES-PORT`, `LES-DASH`. Module repositories use the three-letter module code: `LES-FIN`, `LES-EDU`, and so on. Exception: `LES-demo-data` uses lowercase because it is not a module — it is a tooling repository. The lowercase differentiates it visually. *** ### Universal Folder Structure Every repository in the LES architecture follows the same internal folder structure (Decision 33). This universality means that any contributor — or any reader navigating the repositories — knows where to find a given type of content without consulting documentation. ``` LES-[MODULE]/ ├── README.md ├── src/ │ └── tests/ ├── docs/ │ ├── architecture/ │ │ └── diagrams/ │ ├── decisions/ │ │ └── TEMPLATE.md │ ├── governance/ │ │ └── TEMPLATE.md │ ├── research/ │ │ └── TEMPLATE.md │ ├── roadmap/ │ │ └── TEMPLATE.md │ └── specs/ │ └── TEMPLATE.md ├── journal/ │ └── TEMPLATE.md └── TEMPLATE.md ``` **Folder purposes:** | Folder | Contents | | ----------------------------- | ------------------------------------------------ | | `src/` | Source code for this module | | `src/tests/` | Tests for this module's source code | | `docs/architecture/` | Architecture documents (`LES-ARCH-000[NNN]`) | | `docs/architecture/diagrams/` | Diagrams (`LES-DIAG-000[NNN]`) | | `docs/decisions/` | Architecture Decision Records (`ADR-YYYY-MM-DD`) | | `docs/governance/` | Governance frameworks (`LES-GOV-000[NNN]`) | | `docs/research/` | Research notes (`LES-RES-000[NNN]`) | | `docs/roadmap/` | Roadmap documents (`LES-ROAD-000[NNN]`) | | `docs/specs/` | Module specifications (`LES-[MOD]-000[NNN]`) | | `journal/` | Learning journal entries (`LES-JOUR-000[NNN]`) | Every folder contains a `TEMPLATE.md` file that establishes the structure for documents of that type (Decision 21). This ensures that a new document in any folder has a consistent starting point. *** ### Naming and Commit Conventions | Element | Convention | Example | | -------------- | -------------------------------- | ---------------------------------------------- | | Repository | `LES-[UPPERCASE]` | `LES-FIN` | | Commit message | `[Session type] — [description]` | `LES-WEBSITE-002 — Full styling pass complete` | | Branch | `[type]/[kebab-description]` | `docs/update-readme` | *** ### Separation from Modules — Special Repositories Three repositories are intentionally separated from the module pattern (Decision 9): * **LES-INFRA** — holds all Azure Infrastructure as Code. Infrastructure is a cross-cutting concern and does not belong in any single module repository. * **LES-API** — holds the central API gateway. All inter-module communication passes through a defined API layer, not through direct module-to-module calls. * **LES-PORT** — holds the NikiDigitals website documentation, content files, and future custom build assets. The website is a portfolio layer, not a system module. *** ### Related Pages * Portfolio Architecture * Architecture Overview * Document Taxonomy & Coding System * **GitHub:** [github.com/NikiDigitals](https://github.com/NikiDigitals) * **Website:** [nikidigitals.com](https://nikidigitals.com) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://nikidigitals.gitbook.io/les/02-project-governance/repository-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.