Platform / Architecture

チームの立ち上がりを速くし、安定した出荷と標準維持を支えるアーキテクチャ

Gumon Platform は、プロジェクトごとに繰り返される構造的なセットアップを減らし、長期的に拡張できる production-ready baseline をチームに提供するために設計されています。

このアーキテクチャ参照は、チーム横断の設計判断を揃えるためのものです。実装スタイルを一つに固定するものではありませんが、デリバリーのぶれを減らします。

Layer

Application Layer

業務フローやユーザー向けサービスを柔軟かつ壊れにくい形で扱います。

Layer

API Service Layer

共有 API 契約と統合標準を定義し、チーム横断の連携を予測可能にします。

Layer

Data Stream Layer

高スループットのイベント処理、非同期処理、可観測性を支えます。

Core Services

チームがすぐに採用できる再利用可能な構成要素

  • - 基盤システム構造としての Gumon Core
  • - 認証と認可のための Auth / Access Control / Profile
  • - 再利用可能な基礎サービスとしての Notification / Schedule / Storage
  • - bootstrap、configuration、operations、extension のための CLI commands

Platform Principles

チーム拡大時にもシステムを安定させる設計原則

  • - 実務で使え、監査しやすい open core
  • - エンジニアリング、運用、デリバリーチームをまたぐ共有標準
  • - 繰り返しセットアップを最小限に抑える scale-ready architecture
  • - ドキュメントと実務は製品の一部であり、付録ではない

High-Level Architecture

各レイヤーの内部構成

上記の図は、レイヤーの数とそれらの接続方法を示しています。このセクションではさらに一歩踏み込み、各レイヤーの構成要素、その役割、そしてビジネスチームやエンジニアリングチームが得られるメリットについて説明します。

Cloud Server Zone

Data Stream Layer

Event Base

各システムが他のシステムのデータベースを直接読み書きするのではなく、システム間でイベントを受け渡すことで、システムの一貫性を保ちます。

このレイヤーの構成要素

  • - Event streaming — プラットフォーム全体で発生した事象の連続的な流れ
  • - Data pipelines — システム間でデータを変換および転送する経路
  • - Message brokers — 転送中にメッセージが失われないことを保証するキュー
  • - Data synchronization — 複数システム間で同一レコードの整合性を維持すること

得られる結果

直接的なデータベースの結合ではなくイベントを通じて統合が行われるため、稼働中のシステムを改修することなく新しいシステムを追加できます。

Cloud Server Zone

API Service Layer

Ready to use

構築済みのビジネスサービスがAPIを通じて公開されるため、各プロジェクトで同じ基盤を書き直すことなく、新しいシステムを構築できます。

このレイヤーの構成要素

  • - Point of Sale (POS) — 店頭での販売と決済処理
  • - Customer Relationship Management (CRM) — 顧客情報と関係性の追跡
  • - Content Delivery System (CDS) — 配信先へのコンテンツの配布
  • - Content Management System (CMS) — コンテンツ作成、編集権限、および公開
  • - Inventory Management System (IMS) — 在庫レベルと商品の移動
  • - Production Order System (PO) — 製造オーダーとそのステータス
  • - Human Resource System (HRS) — 人事記録および関連プロセス
  • - Case Management System (CM) — クローズまで追跡されるケースと課題
  • - Booking Management System (BMS) — 予約とリソースのスケジュール管理

得られる結果

空のリポジトリからではなく、すでに機能するサービスから新しいプロジェクトが開始されるため、繰り返しの基礎作業ではなく、クライアントの実際の課題解決に大半の労力を注ぐことができます。

Client Zone

Application Layer

ユーザーが実際に操作する部分

提供されるアプリケーションです。各アプリケーションは、APIレイヤーから必要なサービスのみを呼び出し、それ以上のことは行いません。

このレイヤーの構成要素

  • - E-Commerce Platform — オンライン販売向けのウェブおよびモバイル
  • - E-Learning Platform — オンライン学習とコース配信
  • - Factory ERP — 工場および生産の管理
  • - Call Center App — LINEチャネルを含む、ケースの受付とフォローアップ
  • - Hotel Management App — 予約と客室の運用
  • - Hospital App — モバイルでの患者向けサービス

得られる結果

基盤となる同じプラットフォームが上位のさまざまな製品をサポートし、背後にあるサービスに影響を与えることなくアプリケーションを変更できます。

全レイヤーで共有される機能

Identity & Access

Auth / Access Control / Profile — プラットフォーム全体で単一のIDおよび認証モデルを提供し、プロジェクトごとにサインイン機能を構築し直す必要がありません。

Shared Services

Notification / Schedule / Storage — 通知、スケジュールされたタスク、およびファイルストレージのために、すべてのレイヤーが呼び出すことができる基盤サービスです。

Operations

CLI commands for bootstrap, configuration, operations, and extension — すべてのチームにおいて同一のセットアップおよび保守手順。

この分離が保証するもの

準備が整っていないオプション機能は、システムをダウンさせるのではなく、自身を利用不可として報告しなければなりません — これこそが、レイヤリングを単なる図の上の箱の積み重ね以上のものにしている理由です。障害はそれが属するレイヤー内にとどまり、日常の業務は継続されます。

各レイヤーに記載されている項目は、上記のアーキテクチャ図に示されているリファレンスセットです。実際のプロジェクトでは、そのスコープで必要とされる部分のみを採用します。

チームに連絡