# Getting Started

I just joined the team — where do I start reading?

This guide will help you orient yourself in the codebase, understand the key abstractions, and get up to speed quickly.

## What This Project Does

This is a Java application that handles **order processing**, **product management**, and **structured business data models** for an enterprise system. It manages order creation, product data retrieval, and field-heavy data exchange with external business systems — many of which appear to originate from Japanese business environments, as reflected in field naming conventions and comments.

At its core, the system reads business data from upstream systems (often encoded with Japanese labels), maps it into structured Java objects, and produces orders or product records for downstream consumption.

## Recommended Reading Order

If you're new to this codebase, read the wiki pages in this order:

1. **[Repository Overview](../overview.md)** — High-level project description, architecture diagram, and tech stack summary. Read this first.
2. **Entry points: `OrderProcessor` and `ProductService`** — The two service classes that drive the application. Start with `OrderProcessor` (the most documented) and then skim `ProductService`.
3. **Data models: `LargeFieldMap` and `LargeBusinessLabelClass`** — These classes define the bulk of the domain's data structure. Skim the field names to understand the scope of business data being handled.
4. **Entity classes** — `MultiPattern`, `EucJpClass`, `MixedLabelClass`, and `PartialLabelEntity` fill in the remaining domain details.

## Key Entry Points

These classes are your starting point for understanding the codebase:

### `OrderProcessor` — Main business entry point

The most important class to read first. It contains the primary `createOrder` method that handles order creation logic. It is well-documented with Javadoc and references multiple data model classes to build order objects.

### `ProductService` — Product data access

The simplest service class. It stores a `productId` and exposes it through a `getProduct` getter. Use this to understand the project's coding style and conventions before diving into the more complex classes.

### `LargeBusinessLabelClass` — Comprehensive business label schema

The largest data model in the project with 50 string fields (`field01` through `field50`). This is likely used to serialize/deserialize large payloads from external business systems. Skim it to understand the full scope of the label schema.

### `LargeFieldMap` — Service processing data model

A 10-field model mapping structured business data for service processing workflows. Fields include a template ID, identification code, service contract number, and several classification/division fields. This is the backbone of the business data domain.

### `MultiPattern` — Contract processing entity

A small 3-field entity for contract number, processing division, and movement division. It was modified under a tracked change request, so look for its changelog if you need history context.

### `EucJpClass` — User-organization record

Maps user IDs, organization codes, and status divisions — likely representing a user-organization relationship record.

### `MixedLabelClass` and `PartialLabelEntity` — Hybrid label entities

These classes mix labeled fields (with Japanese comments) alongside unlabeled fields. They likely represent transitional or integration objects that bridge different data formats.

## Project Structure

The project follows a simple flat package layout:

```
src/main/java/
    A.java                           -- Placeholder / base class stub
    EucJpClass.java                  -- User-organization entity
    LargeBusinessLabelClass.java     -- 50-field business label DTO
    LargeFieldMap.java               -- 10-field service processing model
    MixedLabelClass.java             -- Mixed-labeled entity
    MultiPattern.java                -- Contract processing entity
    OrderProcessor.java              -- Main order creation service (entry point)
    PartialLabelEntity.java          -- Alternating labeled/unlabeled entity
    ProductService.java              -- Product data access service
```

There are no sub-packages. This is a lean, framework-free project — no Spring, no Hibernate, no complex module structure.

### Architecture

```mermaid
flowchart LR
    subgraph services["Services"]
        OP["OrderProcessor"]
        PS["ProductService"]
    end

    subgraph models["Data Models"]
        MPA["MultiPattern"]
        LFM["LargeFieldMap"]
        MBC["LargeBusinessLabelClass"]
    end

    subgraph entities["Entities"]
        EJC["EucJpClass"]
        MLB["MixedLabelClass"]
        PLE["PartialLabelEntity"]
        A["A"]
    end

    OP --> MPA
    OP --> LFM
    OP --> MBC
    PS --> MBC
    PS --> PLE
    EJC --> MBC
    MLB --> MBC
    PLE --> LFM
```

The architecture is straightforward:

- **Services** (`OrderProcessor`, `ProductService`) are the entry points that orchestrate business logic.
- **Data Models** (`MultiPattern`, `LargeFieldMap`, `LargeBusinessLabelClass`) define the structures used by services to represent business data.
- **Entities** (`EucJpClass`, `MixedLabelClass`, `PartialLabelEntity`, `A`) provide domain-specific records. `LargeBusinessLabelClass` is a shared dependency across most entities.

## Configuration

This is a minimal project with no external configuration files detected. Key points:

- **No build tool config files found** (no `pom.xml`, `build.gradle`, or `settings.gradle` in the current layout). A standard Java build tool (Maven or Gradle) is assumed.
- **No application config** — properties, YAML, or environment files were not detected. The project uses plain Java objects with no dependency injection or externalized configuration.
- **Version markers** — some source files contain version-control-style markers (e.g., `ANK-4494-00-00` in `MultiPattern.java`), suggesting changes are tracked through a change request system. Check with the team for how to access change history.

## Common Patterns

### Plain Old Java Objects (POJOs)

All data models are simple classes with string fields and no external framework dependencies. Each field typically has a descriptive comment (many in Japanese) indicating its business meaning.

### Field-heavy data transfer objects

`LargeBusinessLabelClass` (50 fields) and `LargeFieldMap` (10 fields) follow a flat field naming convention (`field01`-`field50` or domain-specific names like `templateID`, `identifyCD`, `key_svc_kei_no`). These are likely used for direct serialization to/from external systems.

### Japanese locale conventions

Many field names and comments are in Japanese or use Japanese romanization (e.g., `syoriDiv`, `idoDiv`, `kinoDiv`, `jokaiDiv`). This suggests the system processes data from Japanese business environments. Do not rename these fields without understanding their external contract.

### Service-driven architecture

Business logic is centralized in service classes (`OrderProcessor`, `ProductService`). Data models are passive DTOs. If you need to add a new business operation, start with a new service method. If you need a new data structure, add a new entity or extend an existing DTO.

### Tracked change management

Version markers like `ANK-4494-00-00` appear in source files. Coordinate with the team before modifying tracked files to ensure change requests are properly referenced.

## Quick Start Checklist

- [ ] Read [Repository Overview](../overview.md) for the full architecture picture
- [ ] Open `OrderProcessor.java` — it's the most documented class and the main entry point
- [ ] Open `ProductService.java` — the simplest service, great for understanding code style
- [ ] Skim `LargeFieldMap.java` and `LargeBusinessLabelClass.java` to understand the data domain
- [ ] Review the entity classes for remaining domain details
- [ ] Compile and run with your build tool to confirm the environment is set up
- [ ] Trace `OrderProcessor.createOrder()` end-to-end to understand data flow