# Getting Started

Welcome! If you're just stepping into this codebase, you've come to the right place. This guide will help you orient yourself in the first 15 minutes.

## What This Project Does

This is a Java application that models an order processing pipeline. At its core, it ingests orders, associates them with products, manages several types of business labels, and maps structured fields for data transformation. It also includes explicit support for EUC-JP character encoding, suggesting integration with Japanese-language data sources.

The codebase is intentionally compact — nine classes across a single package — with a centralized `LargeFieldMap` data structure that serves as the shared model between all components.

## Recommended Reading Order

Read these wiki pages in order to build a mental model of the system efficiently:

1. **[Repository Overview](/codewiki/overview)** — High-level summary of the project, technology stack, and architecture.
2. **`LargeFieldMap.java`** — The central data structure; understanding its fields makes every other class click into place.
3. **`OrderProcessor.java`** — The primary entry point that orchestrates the order workflow.
4. **`ProductService.java`** — The companion service for product-related operations.
5. **Label classes** — `LargeBusinessLabelClass`, `MixedLabelClass`, and `PartialLabelEntity` to understand the labeling domain.
6. **Utility classes** — `EucJpClass` (encoding) and `MultiPattern` (pattern matching) if you need deeper context.

Reading all nine source files end-to-end will give you a complete picture of how the system works.

## Key Entry Points

These are the classes you should understand first:

### LargeFieldMap

The shared data carrier. It defines 10 string fields used across the entire codebase — order IDs, status flags, division codes, and membership numbers. Nearly every other class references these fields, so start here.

- **File**: `src/main/java/LargeFieldMap.java`
- **Why first**: It is the dependency that all other classes depend on.

### OrderProcessor

The main workflow entry point. It exposes `createOrder(String orderId)` and is the starting point for tracing the order lifecycle.

- **File**: `src/main/java/OrderProcessor.java`

### ProductService

The product-side counterpart. Provides `getProduct()` and manages product IDs associated with orders.

- **File**: `src/main/java/ProductService.java`

### LargeBusinessLabelClass

The largest class in the project (50 fields). It models a business label with a broad set of Japanese-language fields, likely representing the primary label type used in production.

- **File**: `src/main/java/LargeBusinessLabelClass.java`

## Project Structure

All classes live in the default package under `src/main/java/`:

```
src/
  main/
    java/
      A.java                         # Placeholder / marker class
      EucJpClass.java                # EUC-JP character encoding model
      LargeBusinessLabelClass.java   # Large business label data model (50 fields)
      LargeFieldMap.java             # Central field mapping structure
      MixedLabelClass.java           # Mixed label type (labeled + unlabeled fields)
      MultiPattern.java              # Multi-pattern matching data model
      OrderProcessor.java            # Order workflow entry point
      PartialLabelEntity.java        # Partial label entity model
      ProductService.java            # Product management entry point
```

There are no sub-packages; the entire application is flat.

```mermaid
flowchart TD
    OP["OrderProcessor"] --> LFM["LargeFieldMap"]
    PS["ProductService"] --> LFM["LargeFieldMap"]
    LFM --> MP["MultiPattern"]
    LFM --> LBLC["LargeBusinessLabelClass"]
    LFM --> MLC["MixedLabelClass"]
    LFM --> PLE["PartialLabelEntity"]
    LFM --> EJC["EucJpClass"]
```

`LargeFieldMap` sits at the center. `OrderProcessor` and `ProductService` are the entry-point services. All label and utility classes depend on `LargeFieldMap` for field data.

## Configuration

This project is self-contained and does not use external configuration files (no `pom.xml`, `build.gradle`, `application.yml`, or `.properties` files are present in the repository). All behavior is driven by Java class definitions and field assignments.

If configuration is needed, it will likely be added via a standard Java build tool — `pom.xml` (Maven) or `build.gradle` (Gradle) — as the project evolves.

## Common Patterns

### Centralized Data Model

`LargeFieldMap` is the single source of truth for structured data. Instead of passing domain objects between services, the codebase uses this flat key-value-like structure to carry context. This keeps the code simple but means field naming discipline is important.

### Label Hierarchy

The codebase distinguishes three label types:

- **LargeBusinessLabel** — Full business label with 50 fields.
- **MixedLabel** — Combines labeled and unlabeled fields, some in Japanese, some in English.
- **PartialLabelEntity** — Incomplete label for incremental construction.

All three coexist because the pipeline may need different label granularity at different stages.

### Japanese Localization

Multiple classes use Japanese comments and field names:

- `EucJpClass` — Explicitly handles EUC-JP encoding (a legacy Japanese character set).
- `LargeBusinessLabelClass` — All 50 field comments are in Japanese.
- `MixedLabelClass` — Mix of Japanese and English field comments.

This signals that the application processes Japanese-language data, and the encoding class likely exists to bridge between legacy systems and modern Java's UTF-8 default.

### Naming Convention

- Classes use **PascalCase** (e.g., `OrderProcessor`).
- Fields use a mix of **snake_case** and **camelCase** conventions, many with Japanese comments indicating their purpose.
- Some fields (e.g., `key_svc_kei_no`, `syoriDiv`, `idoDiv`) appear to be abbreviated codes from a larger Japanese enterprise system.

### Minimal Dependencies

The project uses no external frameworks or libraries beyond the Java standard library. `OrderProcessor` and `ProductService` are plain classes with no Spring annotations, no dependency injection, and no test harness visible. This is a focused, framework-free codebase designed for clarity.