> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fusioncore.us/llms.txt
> Use this file to discover all available pages before exploring further.

# Developer Guide Overview

> Orientation for developers building on fusionCore: the package model, coding standards, and the shared infrastructure to build on.

fusionCore is a solution built on top of Salesforce that supports member-based organizations. Internally, it is a collection of managed and unmanaged packages rather than a single application. To be productive as a developer, you need to know three things: how to set up a development environment, how to follow the fusionCore coding conventions, and how to use the common tools, frameworks, and utilities the platform provides. This section covers the last two — the coding conventions and the shared infrastructure; the pages below are your starting point.

## How fusionCore Is Packaged

fusionCore ships as a mix of **managed** and **unmanaged** packages. The managed packages carry a global namespace, so the metadata they expose is referenced from a subscriber org with a namespace prefix. The three core packages and their namespaces are:

* **Platform** — `FCORE_BASE`
* **Commerce** — `FCORE_PAY`
* **Subscriptions** — `FCORE_MEM`

When you reference managed-package Apex or SObjects from another package or a subscriber org, you use the namespaced name, for example `FCORE_BASE.ServiceLayer` or `FCORE_PAY__Wallet_Item__c`.

You can tell whether a given package is managed or unmanaged from the `namespace` field in its `sfdx-project.json`: a populated `namespace` means the package is managed, while an empty or missing `namespace` means it is unmanaged. Unmanaged-package metadata does not carry a Salesforce namespace, so each unmanaged package instead applies its own per-package prefix to its API names. That prefix is documented near the top of the package's `README.md` under **Development Conventions**.

## The Shared Infrastructure

The platform provides several key pieces of shared infrastructure that the rest of fusionCore builds on. Learn these before writing feature code:

* **Logging** — structured logging for capturing diagnostic output and errors in a consistent, queryable way.
* **Caching** — per-transaction caching that holds reusable data in memory for the life of a single transaction.
* **DB classes** — the per-object query pattern that centralizes how each object's records are queried and retrieved.
* **Utility functions** — the smaller reusable helpers for collection manipulation, validation, describe calls, and LWC support.
* **Trigger Framework** — metadata-driven control over triggers, including ordering and the ability to turn specific triggers off programmatically or through custom metadata. It also supports validation-only triggers.
* **Event Framework** — an in-memory hook system, *not* standard Salesforce platform events. One package defines extension points, and other packages register handlers that run synchronously when an event fires.
* **Services** — common multi-step tasks grouped into service classes that bundle the code, event hooks, and supporting metadata for a task.

<CardGroup cols={2}>
  <Card title="Coding Standards" icon="book" href="/developer-guide/coding-standards">
    The conventions every fusionCore package follows — naming, structure, and API-name prefixes.
  </Card>

  <Card title="Logging" icon="file-lines" href="/developer-guide/logging">
    Structured logging for capturing diagnostic output and errors in a consistent way.
  </Card>

  <Card title="Caching" icon="bolt" href="/developer-guide/caching">
    Per-transaction caching that holds reusable data in memory for a single transaction.
  </Card>

  <Card title="DB Classes" icon="database" href="/developer-guide/db-classes">
    The per-object query pattern that centralizes how each object's records are retrieved.
  </Card>

  <Card title="Utility Functions" icon="screwdriver-wrench" href="/developer-guide/utility-functions">
    The smaller helpers for collection manipulation, validation, describe calls, and LWC support.
  </Card>

  <Card title="Trigger Framework" icon="code-branch" href="/developer-guide/trigger-framework">
    Metadata-driven trigger ordering and on/off control, including validation-only triggers.
  </Card>

  <Card title="Event Framework" icon="diagram-project" href="/developer-guide/event-framework">
    The in-memory event and handler system packages use to extend each other synchronously.
  </Card>

  <Card title="Services" icon="gears" href="/developer-guide/services">
    Service classes that bundle multi-step tasks with their event hooks and metadata.
  </Card>
</CardGroup>