# Com / Optage / Kopt

## Overview

The `com.optage.kopt` package is a subpackage within the OPTAGE KOPT system that provides batch processing infrastructure for dispatch and transmission operations. It appears to serve a Japanese business context, reflected in its naming conventions (JKK, SOD, Hakko). The package is organized as a thin layer of batch job entry points and SOD (dispatch/send) workflow orchestrators, with the actual business logic delegated to sibling packages such as `com.optage.kopt.ekk`.

All classes in this package are currently auto-generated fixtures for SPEC-SCOPED-WIKI tests. The methods are stubs awaiting implementation, but the structural design — stateless, per-call instantiation with clear delegation — is already in place.

## Sub-module Guide

The module has two child sub-packages, each with a distinct but complementary responsibility:

### `com.optage.kopt.batch` — Batch Job Entry Points

This sub-package defines the execution boundary for batch processing operations. It contains three classes following a `KKPRC` prefix pattern:

- **KKPRC14901** — The primary batch job. Implements `run()` by instantiating `EKK0301A010` from `com.optage.kopt.ekk` and calling its `process()` method. Also has a no-op `check()` stub, likely reserved for pre-flight validation.
- **KKPRC24901** — A secondary batch stub (`/* KKPRC secondary batch */`), awaiting implementation.
- **KKPRC34901** — A tertiary batch stub (`/* KKPRC tertiary batch */`), awaiting implementation.

The batch class acts as a thin facade over handler classes in sibling packages, keeping entry points minimal and pushing business logic into dedicated processors.

### `com.optage.kopt.bp` — SOD Dispatch Processing

This sub-package provides the batch processing layer for SOD (dispatch/send) operations. It coordinates the dispatch, validation, and transmission of SOD data:

- **JKKHakkoSODCC** — The central controller. Its `dispatch()` method creates and delegates to `JKKSodSendCC.send()`, while its `validate()` method delegates to `KKPRC14901.check()` from the `batch` package. This class bridges the `batch` and `bp` sub-packages.
- **JKKSodSendCC** — The send handler that executes the actual SOD dispatch workflow.
- **JKKHakkoSODHelper** — A pure utility for string normalization (whitespace trimming).
- **JKKBpServiceBase** — A base class with a `baseInit()` stub, serving as an extension point for shared initialization logic.
- **JKKHakkoSODCCTest** — A placeholder JUnit 4 test class.

### How the Sub-modules Relate

The relationship between `batch` and `bp` is one of **shared infrastructure**:

1. `bp` depends on `batch` for validation — `JKKHakkoSODCC.validate()` instantiates `KKPRC14901` and calls its `check()` method.
2. `batch` depends on `bp`'s sibling package `com.optage.kopt.ekk` for actual processing — `KKPRC14901.run()` delegates to `EKK0301A010.process()`.
3. Both sub-packages follow the same architectural pattern: stateless, short-lived objects instantiated per-call, with business logic pushed into handler classes in sibling packages.

```mermaid
flowchart LR
    subgraph Batch["com.optage.kopt.batch"]
        K1["KKPRC14901
Primary batch"]
        K2["KKPRC24901
Secondary batch
(stub)"]
        K3["KKPRC34901
Tertiary batch
(stub)"]
    end

    subgraph Bp["com.optage.kopt.bp"]
        BPCTRL["JKKHakkoSODCC
SOD controller"]
        BPSEND["JKKSodSendCC
send handler"]
        BPHELP["JKKHakkoSODHelper
string utility"]
        BPBASE["JKKBpServiceBase
base class"]
    end

    BPCTRL -->|"dispatches to"| BPSEND
    BPCTRL -.->|"validates via"| K1
    BPCTRL -.->|"uses"| BPHELP
    BPCTRL -.->|"extends"| BPBASE

    subgraph External["External modules"]
        EKKP["com.optage.kopt.ekk
processing logic"]
    end

    K1 -->|"processes"| EKKP
```

## Key Patterns and Architecture

### Stateless Delegation

Every class in both sub-packages follows a stateless, per-call instantiation pattern. Rather than using dependency injection or singletons, objects create their dependencies inline. For example:

- `JKKHakkoSODCC.dispatch()` creates `new JKKSodSendCC()` and calls `send()`.
- `KKPRC14901.run()` creates `new EKK0301A010()` and calls `process()`.

This keeps the code simple and easy to reason about but may limit testability and flexibility if the classes grow in complexity.

### Thin Facade / Handler Separation

Batch entry points are designed to be thin. The actual business logic lives in handler classes in sibling packages (`com.optage.kopt.ekk` for batch processing). New batch jobs should create their handler in a sibling package rather than embedding logic directly in the batch class.

### Shared Base Class Extension Point

`JKKBpServiceBase` provides a `baseInit()` protected method that any extending or related class can invoke for common setup (e.g., loading configuration, setting up connections). This is the recommended extension point for adding shared initialization logic.

### Naming Convention

The `KKPRC` prefix in `batch` classes and the `JKK` prefix in `bp` classes suggest these are part of a larger family of components, likely encoding business context (module, sequence number, or job type) within the broader OPTAGE application. The SOD naming (HakkoSOD) indicates the package handles Japanese business dispatch workflows.

## Dependencies and Integration

### Internal Dependencies

| Dependency | Consuming Class | Purpose |
|---|---|---|
| `com.optage.kopt.ekk.EKK0301A010` | `KKPRC14901` | Actual batch processing logic |
| `com.optage.kopt.batch.KKPRC14901` | `JKKHakkoSODCC` | Validation via `check()` |

### External Dependencies

| Dependency | Usage |
|---|---|
| `org.junit` | Test classes (`JKKHakkoSODCCTest`) |

The module sits between batch scheduling (external schedulers invoke `run()` on `KKPRC` classes) and downstream processing logic in sibling packages. It does not define any entity, DTO, or model classes — data flows through the system as method parameters.

## Notes for Developers

- **Everything is a stub.** All classes are auto-generated fixtures. No business logic is implemented yet. This is a structural skeleton awaiting content.
- **Follow the delegation pattern.** When implementing new batch jobs, create the business logic in a handler class in a sibling package (such as `com.optage.kopt.ekk`) and have the `run()` method in the batch class instantiate and delegate to it.
- **Use `baseInit()` for shared setup.** If you need common initialization logic (configuration loading, connection setup), extend or call `JKKBpServiceBase.baseInit()` rather than duplicating code.
- **Tests need fleshing out.** `JKKHakkoSODCCTest.testMain()` uses `assertTrue(true)` as a placeholder. Write real tests alongside business logic.
- **The `check()` method in `KKPRC14901` is a no-op.** This appears to be a planned pre-flight validation step that a batch runner could invoke before `run()`.
- **`KKPRC24901` and `KKPRC34901` are unimplemented.** Follow the pattern established by `KKPRC14901` when implementing these — delegate to an appropriate handler in a sibling package.