ChatGPT と Google Bard の結果比較（在庫管理を題材にしたDDD設計を例に）

投稿日: 投稿者: 上拾石 弘（Hiroshi Kamijikkoku）

株式会社光翼では、DX推進のコンサルティングを行っております。

今日は、ChatGPT と Google Bard の結果比較をシステム開発における「在庫管理を題材にしたDDD（ドメイン駆動設計）」を例に比較してみたいと思います。

投入したプロンプト

■プロンプト①
あなたは一流のシステムエンジニアです。 在庫管理を題材にしてDDD（ドメイン駆動設計）の説明をしてください。

■プロンプト②
では、実際にその説明に従って、「在庫管理」の設計を文章で説明してください。

■プロンプト③
次に、実際にその説明にしたがって、クラス図で、表現してください。

ChatGPT-3.5 の結果

■プロンプト①
あなたは一流のシステムエンジニアです。 在庫管理を題材にしてDDD（ドメイン駆動設計）の説明をしてください。

もちろんです。在庫管理を題材にして、ドメイン駆動設計（DDD）について説明します。

ドメイン駆動設計（DDD）とは？

ドメイン駆動設計は、ソフトウェア開発において、ビジネスドメイン（業務領域）に焦点を当て、そのドメインの理解を深め、ソフトウェアをそれに合わせて設計する手法です。DDDでは、ビジネスドメインの概念、ルール、プロセスをモデル化し、それをソフトウェアに反映させることが重要視されます。

在庫管理とDDD

在庫管理は、企業にとって重要なプロセスの一つです。ドメイン駆動設計を適用する際には、まずビジネスのコアドメイン（重要な業務領域）を特定します。在庫管理においては、商品や在庫、注文などがそのコアドメインに該当するでしょう。

1. 職務とエンティティの特定

まず、在庫管理の中でどのような職務が存在するかを特定します。例えば、倉庫管理担当者、注文処理担当者などが考えられます。そして、これらの職務が操作するエンティティ（物理的または概念的な対象）を特定します。商品や在庫などがエンティティの例です。

2. アグリゲートとリポジトリの設計

次に、アグリゲートと呼ばれる関連するエンティティのグループを定義します。例えば、注文とその注文に関連する商品や在庫が一つのアグリゲートになります。アグリゲートにはルートエンティティと呼ばれる主要なエンティティが含まれ、他のエンティティはそれに従属します。

アグリゲートに対しては、リポジトリを作成し、データの永続化や取得を行います。これにより、データベースとの対話を抽象化し、ビジネスロジックとデータアクセスを分離します。

3. ドメインサービスとバリューオブジェクト

ドメインサービスは、ビジネスロジックを表現するためのサービスで、アグリゲート間の操作や特定のルールの実施などを担当します。例えば、在庫が一定数以下になった場合に通知するサービスが考えられます。

バリューオブジェクトは、単なるデータ保持のためのオブジェクトでなく、特定の意味を持つ不変のオブジェクトです。例えば、金額や数量が該当します。

4. ユビキタス言語の使用

ビジネスチームと開発チームが共通の言語を使用することが重要です。このユビキタス言語を通じて、要件や仕様の理解を深め、コミュニケーションの齟齬を減少させます。

まとめ

ドメイン駆動設計は、在庫管理のような複雑なビジネスプロセスを効果的かつ柔軟にモデル化する手法です。ビジネスの要件と開発者の理解を統一し、ソフトウェア開発を成功させるために役立ちます。

■プロンプト②
では、実際にその説明に従って、「在庫管理」の設計を文章で説明してください。


在庫管理の設計において、ドメイン駆動設計（DDD）の原則に基づいたアプローチを以下に示します。

1. 職務とエンティティの特定

職務:

  1. 倉庫管理担当者 (WarehouseManager):
    • 倉庫内の商品の配置と移動を担当。
    • 在庫の更新と管理を行う。
  2. 注文処理担当者 (OrderProcessor):
    • 顧客からの注文を処理し、在庫の引当と出荷を担当。
    • 在庫不足時に通知を受け取り、補充を管理。

エンティティ:

  1. 商品 (Product):
    • 商品コード、商品名、価格などの情報を持つ。
    • 在庫アグリゲート内の一部。
  2. 在庫 (Inventory):
    • 商品ごとに数量を管理。
    • アグリゲートのルートエンティティ。
  3. 注文 (Order):
    • 注文ID、注文日時、注文アイテムなどを含む。
    • アグリゲート内のルートエンティティ。

2. アグリゲートとリポジトリの設計

  • 在庫アグリゲート:
    • ルートエンティティ: 在庫
    • 従属エンティティ: 商品
    • 在庫の永続化と取得を担当するリポジトリを設計。
  • 注文アグリゲート:
    • ルートエンティティ: 注文
    • 従属エンティティ: 注文アイテム (注文された商品と数量)
    • 注文の永続化と取得を担当するリポジトリを設計。

3. ドメインサービスとバリューオブジェクト

ドメインサービス:

  1. 在庫通知サービス (InventoryNotificationService):
    • 在庫が一定数以下になった場合に通知を生成するサービス。

バリューオブジェクト:

  1. 金額 (Amount):
    • 通貨と金額をカプセル化したバリューオブジェクト。

4. ユビキタス言語の使用

開発チームとビジネスチームは以下のユビキタス言語を使用:

  • “在庫”、”商品”、”注文”、”倉庫管理担当者”、”注文処理担当者”など。

このようなDDDの設計により、在庫管理システムはビジネスの要件にマッチし、柔軟かつ拡張可能な構造を持つことが期待されます。アグリゲートやリポジトリを使用することでデータの整合性を保ち、ドメインサービスやバリューオブジェクトを通じてビジネスロジックを効果的に実装できます。

■プロンプト③
次に、実際にその説明にしたがって、クラス図で、表現してください。

クラス図は図やグラフィカルな要素がないテキストベースの環境で説明するのが難しいですが、クラス図を簡潔に表現するためのテキスト表現を以下に示します。ただし、これはあくまで概念的な表現であり、具体的なシステムやプログラミング言語に依存するものではありません。

+------------------+          +------------------+        +------------------+
|    Warehouse    |          |     Inventory    |        |      Order       |
| - warehouseId    |          | - productId      |        | - orderId        |
| - manager: WarehouseManager| | - quantity       |        | - orderDate      |
|                  |          | - product: Product|        | - items: List<OrderItem>|
+------------------+          +------------------+        +------------------+
          |                              |                         |
          |                              |                         |
          v                              v                         v
+------------------+       +------------------+         +------------------+
|    Product     |         | OrderItem |            |  InventoryNotification|
| - productId      |       | - productId  |         |   Service        |
| - name            |       | - quantity   |         +------------------+
| - price           |       +------------------+
+------------------+

このクラス図では、Warehouse、Inventory、Order、Product、OrderItem、InventoryNotificationService のクラスが示されています。各クラスはそれぞれの特定の責務を果たしており、クラス間の関連も示されています。ただし、具体的なメソッドやプロパティの詳細は省略しています。

このクラス図を基に、実際の開発言語やフレームワークに合わせて具体的なクラス実装を行うことが求められます。

Google Bard の結果

■プロンプト①
あなたは一流のシステムエンジニアです。 在庫管理を題材にしてDDD（ドメイン駆動設計）の説明をしてください。

DDD（ドメイン駆動設計）とは、ソフトウェア開発において、ドメインの知識をモデル化することで、ソフトウェアの複雑性を管理するための設計手法です。

在庫管理を題材にしてDDDを説明すると、まず、在庫管理のドメインを定義する必要があります。ドメインとは、ソフトウェアが扱う問題領域のことです。在庫管理のドメインでは、以下の要素が考えられます。

  • 商品
  • 在庫
  • 入庫
  • 出庫
  • 引当
  • 棚卸

次に、ドメインの知識をモデル化します。モデルとは、ドメインの知識を表現したものです。在庫管理のドメインモデルでは、以下の要素が考えられます。

  • 商品モデル
  • 在庫モデル
  • 入庫モデル
  • 出庫モデル
  • 引当モデル
  • 棚卸モデル

商品モデルでは、商品の名称、型番、単価などの情報を表現します。在庫モデルでは、商品の在庫数、ロット番号、棚番号などの情報を表現します。入庫モデルでは、商品の入庫日時、数量、単価などの情報を表現します。出庫モデルでは、商品の出庫日時、数量、単価などの情報を表現します。引当モデルでは、商品の引当日時、数量、単価などの情報を表現します。棚卸モデルでは、商品の棚卸日時、数量、単価などの情報を表現します。

ドメインモデルを作成したら、そのモデルをソフトウェアに実装します。実装する際には、以下の原則を守るとよいでしょう。

  • ドメインモデルを疎結合にする
  • ドメインモデルを独立させる
  • ドメインモデルをテストしやすいようにする

ドメインモデルを疎結合にすると、ドメインモデルの変更の影響を小さく抑えることができます。ドメインモデルを独立させると、ドメインモデルを再利用しやすくなります。ドメインモデルをテストしやすいようにすると、ドメインモデルの品質を向上させることができます。

DDDを適用することで、在庫管理システムの以下のメリットが得られます。

  • ドメインの知識がソフトウェアに反映されるため、ソフトウェアの理解が容易になる。
  • ドメインの知識がモデル化されるため、ソフトウェアの保守性が向上する。
  • ドメインの知識がテストされるため、ソフトウェアの品質が向上する。

DDDは、在庫管理システムだけでなく、あらゆる業務システムの設計に適用できる手法です。複雑な業務システムを開発する際には、DDDの適用を検討するとよいでしょう。

以下に、在庫管理システムのDDDの具体例をいくつか示します。

  • ドメインイベントの利用

在庫管理システムでは、商品の入庫や出庫などのイベントが発生します。これらのイベントをドメインイベントとして定義することで、ドメインの変化を明確に表現することができます。

例えば、商品が入庫した際には、以下のようなドメインイベントが発生します。

商品入庫イベント(商品ID, 数量, 単価)

このイベントが発生すると、在庫数や棚卸情報などのドメインモデルが更新されます。

  • アグリゲーションの利用

ドメインモデルを構成するオブジェクトを、意味的に関連のあるグループにまとめることをアグリゲーションと呼びます。アグリゲーションを利用することで、ドメインモデルの構造を明確に表現することができます。

例えば、商品の在庫情報は、商品モデルと在庫モデルの2つのオブジェクトで構成されます。これらのオブジェクトをアグリゲーションとしてまとめることで、商品の在庫情報を一元的に管理することができます。

  • 結果整合性の利用

ドメインモデルの変更によって、ドメインの状態が矛盾しないようにすることを結果整合性と呼びます。結果整合性を保つことで、ドメインの状態の正確性を保つことができます。

例えば、商品の在庫数を更新する際には、必ず棚卸情報も更新するようにします。これにより、商品の在庫数と棚卸情報の整合性が保たれます。

DDDは、在庫管理システムの設計をより効果的に行うための手法です。DDDの原則を理解し、適切に適用することで、在庫管理システムの品質と保守性を向上させることができます。

■プロンプト②
では、実際にその説明に従って、「在庫管理」の設計を文章で説明してください。

在庫管理のDDD設計の例を以下に示します。

ドメインの定義

在庫管理のドメインは、商品の在庫を管理する問題領域です。このドメインでは、以下の要素が考えられます。

  • 商品
  • 在庫
  • 入庫
  • 出庫
  • 引当
  • 棚卸

ドメインモデルの作成

ドメインの知識をモデル化します。以下の要素をドメインモデルとして定義します。

  • 商品モデル
    • 商品の名称、型番、単価などの情報を表現します。
  • 在庫モデル
    • 商品の在庫数、ロット番号、棚番号などの情報を表現します。
  • 入庫モデル
    • 商品の入庫日時、数量、単価などの情報を表現します。
  • 出庫モデル
    • 商品の出庫日時、数量、単価などの情報を表現します。
  • 引当モデル
    • 商品の引当日時、数量、単価などの情報を表現します。
  • 棚卸モデル
    • 商品の棚卸日時、数量、単価などの情報を表現します。

実装

ドメインモデルをソフトウェアに実装します。

  • ドメインモデルを疎結合にする
    • ドメインモデル間の依存関係を最小限に抑えます。
  • ドメインモデルを独立させる
    • ドメインモデルを独立したモジュールとして実装します。
  • ドメインモデルをテストしやすいようにする
    • ドメインモデルをテストしやすいように設計します。

DDDの適用によるメリット

DDDを適用することで、以下のメリットが得られます。

  • ドメインの知識がソフトウェアに反映されるため、ソフトウェアの理解が容易になる。
  • ドメインの知識がモデル化されるため、ソフトウェアの保守性が向上する。
  • ドメインの知識がテストされるため、ソフトウェアの品質が向上する。

DDDの具体例

  • ドメインイベントの利用

在庫管理システムでは、商品の入庫や出庫などのイベントが発生します。これらのイベントをドメインイベントとして定義することで、ドメインの変化を明確に表現することができます。

例えば、商品が入庫した際には、以下のようなドメインイベントが発生します。

商品入庫イベント(商品ID, 数量, 単価)

このイベントが発生すると、在庫数や棚卸情報などのドメインモデルが更新されます。

  • アグリゲーションの利用

ドメインモデルを構成するオブジェクトを、意味的に関連のあるグループにまとめることをアグリゲーションと呼びます。アグリゲーションを利用することで、ドメインモデルの構造を明確に表現することができます。

例えば、商品の在庫情報は、商品モデルと在庫モデルの2つのオブジェクトで構成されます。これらのオブジェクトをアグリゲーションとしてまとめることで、商品の在庫情報を一元的に管理することができます。

  • 結果整合性の利用

ドメインモデルの変更によって、ドメインの状態が矛盾しないようにすることを結果整合性と呼びます。結果整合性を保つことで、ドメインの状態の正確性を保つことができます。

例えば、商品の在庫数を更新する際には、必ず棚卸情報も更新するようにします。これにより、商品の在庫数と棚卸情報の整合性が保たれます。

まとめ

DDDは、在庫管理システムの設計をより効果的に行うための手法です。DDDの原則を理解し、適切に適用することで、在庫管理システムの品質と保守性を向上させることができます。

具体的な設計例としては、以下のようなものが考えられます。

  • ドメインモデルを構成するオブジェクトを、データベースのテーブルと対応させる
  • ドメインイベントを、イベント駆動アーキテクチャの駆動イベントとして利用する
  • アグリゲーションを、マイクロサービスアーキテクチャのマイクロサービスとして実装する

これらの設計を適切に適用することで、在庫管理システムの柔軟性と拡張性を向上させることができます。

■プロンプト③
次に、実際にその説明にしたがって、クラス図で、表現してください。

在庫管理のDDD設計のクラス図を以下に示します。

コード スニペット

classDiagram

class 商品モデル {
  名称 : string
  型番 : string
  単価 : Decimal
}

class 在庫モデル {
  在庫数 : int
  ロット番号 : string
  棚番号 : string
}

class 入庫モデル {
  入庫日時 : DateTime
  数量 : int
  単価 : Decimal
}

class 出庫モデル {
  出庫日時 : DateTime
  数量 : int
  単価 : Decimal
}

class 引当モデル {
  引当日時 : DateTime
  数量 : int
  単価 : Decimal
}

class 棚卸モデル {
  棚卸日時 : DateTime
  数量 : int
  単価 : Decimal
}

商品モデル --> 在庫モデル
入庫モデル --> 商品モデル
出庫モデル --> 商品モデル
引当モデル --> 商品モデル
棚卸モデル --> 商品モデル

このクラス図では、以下の要素を表現しています。

  • ドメインモデル
    • 商品モデル
    • 在庫モデル
    • 入庫モデル
    • 出庫モデル
    • 引当モデル
    • 棚卸モデル
  • アグリゲーション
    • 商品アグリゲーション
    • 入庫アグリゲーション
    • 出庫アグリゲーション
    • 引当アグリゲーション
    • 棚卸アグリゲーション
  • ドメインイベント
    • 商品入庫イベント
    • 商品出庫イベント
    • 商品引当イベント
    • 商品棚卸イベント

商品アグリゲーションは、商品モデルと在庫モデルをまとめたものです。入庫アグリゲーション、出庫アグリゲーション、引当アグリゲーション、棚卸アグリゲーションも、同様にドメインモデルをまとめたものです。

商品入庫イベント、商品出庫イベント、商品引当イベント、商品棚卸イベントは、ドメインイベントです。これらのイベントは、ドメインの状態の変化を表します。

このクラス図は、あくまでも一例です。具体的な設計を行う際には、システムの要件や規模に合わせて、適宜調整する必要があります。

上記クラス設計を 「Visual Studio Code で UML を描こう！」を参考に描画したクラス図が、下記です。

考察

DDD（ドメイン駆動設計）では、今日（2023/12/14）現在では、Google Bard は、少し、冗長な回答になっているようです。今日現在、DDD（ドメイン駆動設計）で、使用するならば、ChatGPT の方に、分があるようです。今後の Google Bard の発展に期待いたします。

なお、Chat GPT でも、「上記回答をMermaid記法で、出力してください」と追加のプロンプトを与えることにより、

classDiagram
  class Warehouse {
    - warehouseId
    - manager: WarehouseManager
  }

  class Inventory {
    - productId
    - quantity
    - product: Product
  }

  class Order {
    - orderId
    - orderDate
    - items: List<OrderItem>
  }

  class Product {
    - productId
    - name
    - price
  }

  class OrderItem {
    - productId
    - quantity
  }

  class InventoryNotificationService {
  }

  Warehouse --|> Inventory
  Inventory --|> Product
  Order --|> OrderItem

という結果も、得ることができます。

株式会社光翼では、このようなAI活用を伴うもの、伴わないもの、ミックスしたものなど、お客様の状況に応じたご提案をいたしております。

ご興味をお持ちの方は、お問い合わせフォームより、お問い合わせくださいませ。

関連記事