業務システムをシンプルに保つ3層構造設計

― 複雑な業務をシンプルに扱う 3 層構造と更新規則 ―

エンジニア向け設計思想ガイド

対象読者：業務システム開発に携わるすべてのエンジニア

0. はじめに ― なぜシステムは修正のたびに壊れるのか

あなたは、こんな経験をしたことはないだろうか。

• 小さな仕様変更のつもりが、まったく別の画面でバグが出た。
• 同じような処理なのに、担当者によって書き方がバラバラで、読解に時間がかかる。
• 「ここを直せばいい」と思ったのに、直す場所が 5 か所もあった。

これらは「スキル不足」ではない。構造の問題だ。

業務システムには、二つの性質がある。

この「複雑な業務」と「シンプルなコンピュータ」をどう繋ぐか。それを整理するのが、本ドキュメントの目的だ。

1. 3 層構造の概要

業務システムの処理は、次の 3 つの責務に分けて設計する。

1-1. 構造の流れ

1-2. 各層の「やること・やってはいけないこと」

2. イベント種別と制御コード

第 1 層は、ユーザー操作を次の 3 種類のイベントとして扱う。それぞれに「制御コード」を付与して第 2 層へ渡す。

2-1. 現代の実装との対応

制御コードの考え方は、現代のイベント駆動アーキテクチャと自然に対応する。

3. 更新層の更新規則

第 3 層（更新層）は、「判断しない」ことが最大の特徴だ。渡されたレコードの各フィールドを、次のルールだけで処理する。

3-1. DELETE コード時の数値処理

DELETE (2) の場合、数値フィールドは「負の値」に変換して渡す。更新層は加算するだけなので、結果として引き算になる。

3-2. 更新規則の擬似コード

function applyRecord(currentRow, updateRecord):
    for each field in updateRecord:
        if field.value is NULL or LOW-VALUE:
            pass  # 何もしない
        elif field.type is NUMERIC:
            currentRow[field.name] += field.value  # 加算（負値なら減算）
        else:  # TEXT / CODE / FLAG / DATE
            currentRow[field.name] = field.value   # 転送
    save(currentRow)

このシンプルさが、更新層をテーブルごとに量産できる根拠だ。ロジックは変わらず、構造だけが増える。

4. トランザクション設計

3 層構造でトランザクションをどう扱うかは、実装環境によって選択肢が異なる。現代の環境では、次のパターンが現実的だ。

4-1. 同期処理（シンプルな構成）

エントリー層 → 正規化・振分け層 → 更新層
↑──────────────────────────┘
1 トランザクション

第 2 層と第 3 層を同一トランザクション内で実行する。RDBMS のトランザクション機能をそのまま使える。多くの業務システムで最初に選ぶべき構成だ。

4-2. 非同期処理（スケールが必要な構成）

エントリー層 ─→ メッセージキュー ─→ 正規化・振分け層 → 更新層
             （イベント永続化）       （非同期コンシューマー）

イベントをメッセージキューに書き込んだ時点でエントリー層のトランザクションを完了させ、後続処理を非同期で行う。スループットが上がる一方、結果整合性の設計が必要になる。

5. 設計ドキュメントの作り方

この 3 層構造を採用するとき、設計の要となるドキュメントは 2 種類だ。個々のプログラム仕様書を書く前に、この 2 つを揃えることで設計の全体像が見えてくる。

5-1. イベント × テーブル更新マトリクス

横軸にテーブル名、縦軸に業務イベント名を並べ、交点に「参照（R）」「更新（W）」を記入する。

R = 参照のみ　W = 更新あり　（空欄）= 関与なし

5-2. イベント × 項目更新定義

マトリクスで「W（更新あり）」となった交点について、どの項目をどう更新するかを定義する。

この定義があれば、第 2 層（正規化・振分け層）の実装は機械的に書ける。属人化しない。

5-3. 「縦の標準化」と「横の拡張性」

この構造の本質的な利点は次の一点に集約される。

「仕様変更＝量的な変化」にとどめ、「構造の質的な変化」を起こさないことが目標だ。

6. よくある疑問と回答

Q1. マスターメンテナンスは「特別扱い」しなくていいのか？

しなくていい。商品マスターの登録・修正・削除も「商品マスター保守イベント」として同じ 3 層で処理する。従来の「マスターファイル」「トランザクションファイル」という区別はこの構造では存在しない。

Q2. 第 1 層でどうしても書き込みが必要な場合は？

採番管理（伝票番号の採番など）のように即時更新が必要なケースは例外として認める。ただし例外はドキュメントに明記し、その数を最小限に抑える。「例外を作りたくなったら構造を疑え」を基本姿勢にする。

Q3. 非同期構成にした場合、整合性は大丈夫か？

結果整合性（Eventual Consistency）を前提とした設計にする必要がある。重要なのは更新層の冪等性だ。同じイベントが 2 回処理されても結果が変わらない設計にしておけば、リトライ・障害復旧が安全に行える。

Q4. バッチ処理も同じ構造で扱えるか？

扱える。バッチ処理も「データ抽出（エントリー相当）→ 正規化・振分け → 更新」という 3 段セットで組み立てる考え方は有効だ。ただし、バッチ特有の大量データ処理や排他制御の考慮は別途必要になる。

Q5. この構造は「古い」のではないか？

構造の骨格は、現代のイベントソーシングや CQRS と本質的に近い。「業務イベントを受け取り、正規化し、データストアに反映する」という分離の考え方は、言語や環境が変わっても通用する。技術スタックは変わるが、問題の本質は変わっていない。

Q6. 正規化・振分け層でデータストアを参照してもよいか？

原則として、正規化・振分け層の入力はイベントレコードのみだ。しかし業務によっては、イベントレコードだけでは更新値を確定できないケースが存在する。代表例が移動平均単価の更新だ。

移動平均単価の計算には「仕入数量・仕入金額（イベントレコードにある）」と「現在の在庫数量・現在の平均単価（在庫マスターにある）」の両方が必要だ。後者はイベントレコードに含まれないため、参照なしに計算できない。

このような場合、正規化・振分け層は「値の補完」を目的に限り、データストアを読み取ることができる。これを「補完参照ルール」として標準に含める。

Q7. これは Event Sourcing の説明ですか？内容が同じに見えます。

部分的に似ていますが、同じではない。

Event Sourcing は「イベントを永続化し、状態をイベントから再構築する」という特定のアーキテクチャパターン。本ドキュメントが扱っているのは、技術に依存しない「業務システムをシンプルに保つための構造原則」となる。

• 業務の複雑さをどこで吸収するか
• 更新ロジックをどう純化するか
• 修正を「削除＋追加」として扱う理由
• 層ごとの責務分離
• 構造を標準化し、変更を量的変化にとどめる方法

といった原則は、Event Sourcing より広い概念であり、Event Sourcing はその一部を実装として具体化したものだ。つまり、「Event Sourcing と似ている」のではなく、「Event Sourcing が本ドキュメントの原則と同じ方向を向いている」という関係になる。

7. まとめ

本ドキュメントで示した原則を一枚に整理する。