# Com / Fujitsu

## Overview

The `com.fujitsu` package serves as the top-level namespace for **Fujitsu-specific code** within the codebase. It acts as the root boundary for all client- or partner-related modules, currently housing the **Futurity** product family — a billing and pricing platform designed for enterprise rate-engineering, financial calculations, and multi-client deployment scenarios.

This package does not contain source files directly. Instead, it functions as an organizational root, with meaningful code organized in child sub-packages under `com.fujitsu.futurity`.

## Sub-module Guide

### futurity

The `com.fujitsu.futurity` package is the primary — and currently only — child of this namespace. It represents the **Futurity product family**, a billing and pricing platform with a layered customization architecture. Key points:

- **Domain focus**: Rate-engineering, pricing calculations, billing cycle management, and financial rule evaluation.
- **Customization model**: Uses a `custom` qualifier pattern to separate standard product behavior from site-specific extensions, enabling a single codebase to serve multiple deployments with divergent rate plans and billing rules.
- **Hierarchy**: Nesting goes four levels deep (`futurity` → `bp` → `custom` → `constant`), with each level refining the scope from product family down to configuration constants.

For a detailed breakdown of `futurity`'s sub-packages (`bp`, `custom`, `constant`), architecture patterns, and dependency relationships, see the [Futurity sub-module documentation](./futurity.md).

## Key Patterns and Architecture

### Hierarchical Package Organization

The `com.fujitsu` namespace establishes a single level of hierarchy before delegating to its children. This pattern is common in enterprise codebases where a client-specific root package contains multiple product domains. Currently, `futurity` is the only domain under this umbrella, but the structure allows for future growth (e.g., `com.fujitsu.another-product`).

### Dependency on Futurity's Customization Model

Since the only meaningful code lives under `futurity`, the architecture of `com.fujitsu` is effectively the architecture of `futurity` itself — specifically, its layered customization model where standard and bespoke logic are kept separate. This model is the single most important architectural decision in this package subtree.

## Dependencies and Integration

### Internal Dependencies

- **No indexed source files**: Neither this module nor its children have indexed source files in the current code index. This means no package-level dependency graph is available. The expected dependencies are described in the [Futurity documentation](./futurity.md).
- **No cross-module relationships detected**: This package does not appear to export public APIs consumed by sibling modules, nor does it import from siblings. It operates as an internal namespace boundary.

### Package Structure

```mermaid
flowchart TD
    Root["com.fujitsu
(Fujitsu codebase root)"] --> Futurity["com.fujitsu.futurity
(Futurity product family)"]
    Futurity --> BP["com.fujitsu.futurity.bp
(billing/pricing domain)"]
    Futurity --> Custom["com.fujitsu.futurity.custom
(customization layer)"]
    BP --> Constants["com.fujitsu.futurity.bp.custom.constant
(configuration constants)"]
    style Root fill:#f5f5f5
    style Futurity fill:#e3f2fd
    style BP fill:#fff3e0
    style Custom fill:#e8f5e9
    style Constants fill:#f3e5f5
```

## Notes for Developers

- **Indexing gap**: No source files have been indexed under this module or its children. If source code exists for these packages, the build configuration or source roots may need to be checked to ensure they are included in indexing.
- **Single child**: Currently, `futurity` is the only child module. If new Fujitsu-related products are added to the codebase, they would naturally nest as siblings under `com.fujitsu`.
- **Customization awareness**: Any developer working in this subtree should understand the `custom` qualification pattern — code in `custom` sub-packages is likely gated by feature flags or deployment-specific configuration, and should not be assumed to always be active.
- **Constants discipline**: The `constant` sub-module pattern (used by `futurity`) should be referenced when looking up configuration keys, rate-plan codes, or feature flags anywhere in this subtree.