# Getting Started

Welcome to the team! If you're new to this codebase, this guide will get you oriented in under 10 minutes.

---

## What This Project Does

This project is a lightweight Java library that structures work around two distinct processing patterns — **PatternA** (processing categorization) and **PatternB** (service identification) — along with a **Mixed** helper class that bridges English and unlabeled data. Think of it as a small toolkit for routing and organizing processing tasks by category, template, and identification code.

The codebase is deliberately minimal: three plain Java classes with no external dependencies beyond the JDK itself.

---

## Recommended Reading Order

| # | Page | Why read it |
|---|------|-------------|
| 1 | [Repository Overview](../overview.md) | The full project picture — architecture, modules, and tech stack |
| 2 | `src/main/java/Mixed.java` | The shared data carrier used across patterns |
| 3 | `src/main/java/PatternA.java` | The first processing pattern (categorization) |
| 4 | `src/main/java/PatternB.java` | The second processing pattern (service identification) |

After reading these three classes in order, you'll have a complete picture of the project's domain model.

---

## Key Entry Points

### `Mixed` — shared data carrier

```
src/main/java/Mixed.java
```

A simple container with two fields:

- **`englishOnly`** — reserved for English-language content only.
- **`unlabeled`** — a generic string for data that hasn't been categorized yet.

This class serves as a fallback or cross-cutting carrier between PatternA and PatternB.

### `PatternA` — processing categorization

```
src/main/java/PatternA.java
```

Holds a single field:

- **`syoriDiv`** (処理区分 — "processing division") — a string that categorizes the type of operation being performed.

Use this pattern to classify work items by their processing type.

### `PatternB` — service identification

```
src/main/java/PatternB.java
```

Holds two fields:

- **`templateID`** (サービスIF_ID — "service IF_ID") — identifies which service interface template applies.
- **`identifyCD`** (識別コード — "identification code") — a code used to uniquely identify a record, request, or entity.

Use this pattern as a routing or dispatch mechanism, matching incoming data against known service templates.

---

## Project Structure

```
.
├── .codewiki/          # Documentation (this wiki)
├── .codwiki/           # Legacy wiki assets
└── src/
    └── main/
        └── java/
            ├── Mixed.java        # Shared data carrier
            ├── PatternA.java     # Processing categorization
            └── PatternB.java     # Service identification
```

The project has no sub-modules and no nested packages. Everything lives in a single flat `src/main/java` directory.

### Architecture at a glance

```mermaid
flowchart TD
    subgraph src["src/main/java"]
        Mixed["Mixed"]
        PatternA["PatternA"]
        PatternB["PatternB"]
    end
    Mixed -->|"bridges"| PatternA
    Mixed -->|"bridges"| PatternB
    PatternA -.->|"independent"| PatternB
```

- **Mixed** is the central carrier — other modules may use it to pass English or unlabeled data between PatternA and PatternB.
- **PatternA** and **PatternB** are structurally independent and do not import from each other.

---

## Configuration

There is no configuration. This is a pure-Java project with:

- **No `pom.xml` or `build.gradle`** — no build tool is configured in this snapshot.
- **No application properties** — no external dependencies or runtime config.
- **No external libraries** — the code compiles against the standard JDK only.

To compile, simply run:

```bash
javac src/main/java/*.java
```

Or import the directory into any IDE as a standard Java module.

---

## Common Patterns

### Plain Data Classes (POJOs)

All three classes follow the same pattern: a public class with private fields and no methods. They are pure data carriers with no behavior. This makes them easy to extend — you can add fields or behavior methods without touching other code.

### String-based categorization

Fields use plain `String` types (initialized to `""`) rather than enums or constants:

```java
private String syoriDiv = "";   // Processing category
private String templateID = ""; // Service interface template
```

This keeps the code flexible and framework-agnostic, but means callers are responsible for validating values.

### Independent modules with no cross-dependencies

None of the three classes import from or extend each other. This independence means:

- You can modify one pattern without fear of breaking another.
- New patterns can be added as new classes in the same directory.
- The classes can be used individually without pulling in the others.

### Japanese-language comments

Several fields include Japanese comments (処理区分, サービスIF_ID, 識別コード), suggesting the codebase originates from or targets a Japanese-language team or system. These are field descriptions, not documentation for end users.

---

## Next Steps

Once you're comfortable with these three classes, consider:

- **Adding new fields** to the patterns as requirements evolve.
- **Extending the classes** with behavior methods (they currently hold data only).
- **Integrating them** into a larger application that routes data between the patterns.
- **Adding a build file** (`pom.xml` or `build.gradle`) if the project grows beyond a single directory.
- **Reading the full [Repository Overview](../overview.md)** for deeper architecture details.