常連

ドメインモデルがデータを持つ場合、そのデータは何かしらのデータ構造となってると思いますが、どうやって決めたら良いのでしょうか？例えばマップだとかリストだとか、、、

ドメインモデルが持つデータについて

### 実現したいこと
最近ドメイン駆動開発(DDD)の勉強を始めた初心者です。
teratail(というより質問サイトへの投稿)も初めてです。

仕事ではラダーや組込/制御系(C++/C#)のプログラムを3年くらい書いています。
リポジトリパターンについて分からないことがあり、質問させて頂きました。


### 発生している問題・分からないこと
リポジトリパターンでネットの記事を調べていると、例外処理の記述がありません。

例えばリポジトリ経由でDAOからDB接続して失敗した場合、DB接続異常のハンドリングはDAO内で完結させ、アプリケーション側では全く意識しないという認識でよろしいでしょうか？
DB接続異常の画面表示や、通信先装置への異常応答をどうやって行うのだろうと疑問に思った次第です。




### 該当のソースコード

```
特になし
```

### 試したこと・調べたこと
- [x] teratailやGoogle等で検索した
- [ ] ソースコードを自分なりに変更した
- [ ] 知人に聞いた
- [ ] その他

##### 上記の詳細・結果
Stack Overflow でも似たような質問を見ましたが、少し考えと異なっていたたため、質問させて頂きました。

### 補足
特になし

【DDD】リポジトリパターンでDB切断している時の例外ハンドリングにつきまして

### 前提
C#(WPF)にてクイズゲームのようなアプリを開発しています。
オブジェクト指向についての理解が浅く、どのようにクラスの設計したらよいか迷っています。

### 実現したいこと

クイズのコンテンツ(png,mp3等)をローカルに配置し、それらを参照して画面に表示させたり、音声を再生させるつもりです。
そこで1問のクイズを表すQuizクラスを作成しました。機能としてはローカルの読み取りを行い、適切な形に成形してプロパティにセットするといった内容です。(コンストラクタの引数で取得したいコンテンツ郡を指定しています。)
作っている中で、コンテンツを読み取ることはQuizクラスの責務ではないような気がしていて、クラスを分離したほうが良いのではないかと感じています。しかし具体的にどのようにクラスを設計したら良いかがよく分かりません。
この場合、どのように設計すると良いのでしょうか？

### ソースコード
Quizクラス
```C#
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO;
using System.Linq;

namespace QuizSample
{
    public record Quiz
    {
        private readonly string _contentsPath = @"resources\quizset";

        /// <summary>
        /// 難易度
        /// </summary>
        public string Level { get; init; }

        /// <summary>
        /// 問題文画像
        /// </summary>
        public Question Question { get; init; }

        /// <summary>
        /// 回答ボタン画像
        /// </summary>
        public ReadOnlyCollection<Answer> Answers { get; }

        /// <summary>
        /// </summary>
        /// <param name="level">問題の難易度</param>
        /// <param name="number">問題フォルダの番号</param>
        public Quiz(string level, int number)
        {
            //対象ファイルを取得
            var quizFolder = _contentsPath + @"\" + level + @"\" + number;
            string[] quizElements = Directory.GetFiles(quizFolder);

            //Questionを生成
            var questions = new List<Question>();
            var questionImgPath = quizElements.Where(o => o.Contains("question.png"));
            var questionVoicePath = quizElements.Where(o => o.Contains("question.mp3"));
            var questionPaths = questionImgPath.Zip(questionVoicePath, (iPath, vPath) =>
                new { ImgPath = iPath, VoicePath = vPath });
            foreach (var path in questionPaths)
            {
                var question = new Question(path.ImgPath, path.VoicePath);
                questions.Add(question);
            }
            Question = questions[0];

            //Answersを生成
            var answers = new List<Answer>();
            var answerPath = quizElements.Where(o => o.Contains("answer", StringComparison.CurrentCulture));
            foreach (var path in answerPath)
            {
                var answer = new Answer(path);
                answers.Add(answer);
            }
            Answers = answers.AsReadOnly();
        }
    }
}

```
```コンテンツディレクトリ構成
resources
    └─quizset
       ├─easy
       │  └─1
       │          answer1-correct.png
       │          answer2.png
       │          answer3.png
       │          question.mp3
       │          question.png
       │
       ├─hard
       │  └─1     answer1-correct.png
       │          answer2.png
       │          answer3.png
       │          question.mp3
       │          question.png
       │
       └─normal
          └─1     answer1-correct.png
                  answer2.png
                  answer3.png
                  question.mp3
                  question.png
```
### 補足情報（FW/ツールのバージョンなど）
Visual Studio 2022
C#10.0
WPF


オブジェクト指向のクラス設計について

# 質問
SPA開発におけるAPI設計なのですが、何が良いのかわかりません。
特にGETメソッドのエンドポイントに関してです。

特定のクライアント用のAPIなので、汎用的なものではなく、ある程度、クライアントを意識したもので良いという前提があると思うので、
画面で必要な情報を全て返すAPIエンドポイントを用意してあげるのが良いのでしょうか？

それとも、リソース単位のAPIをクライアントに提供して、クライアント側では必要に応じて、受け取った情報を用いて、計算、判断、加工などの処理を行ってもらうのが良いのでしょうか？

もしくは、「要はバランスだよね」おじさん的な感じになるのでしょうか！？

前提、ビジネスロジックはバック側に持たせるで良いと思うのですが、画面依存させないAPI(リソース単位のAPI)を提供しているとどうしても、フロント側でリソースAの情報の一部と、リソースBの情報の一部をそれぞれ組み合わせて、加工、判断、計算をしないといけないような場面が出てきてしまうと思っています。

例えば、ログインユーザーのロールがXYZというロールで、かつ、帳票が生成済みの場合であれば、ダウンロードボタンを表示、または、活性化させたいような場合、ユーザーリソースに含まれるロール情報と、帳票情報に含まれるステータスの両方をみて、ダウンロード可能かどうかをフロント側で判断しないといけないと思います。

EvansのDDD本にはアンチパターンとしてSmart UIなる表現がありますし、最近、ツイッター界隈ではフロントエンドはJSON色付け係に徹するべなる主張も見かけまして、SPA開発におけるAPIやフロントエンド側のStore設計はどうあるべきなのか、混乱してきたのが質問の背景になります！

※ EvansのDDD本にあるSmart UIのUIはViewとControllerの両方を含んだプレゼンテーション層を指していると解釈しています。

以下、メリデリ考えてみました。

## 画面単位のAPIエンドポイントを用意する場合
### 前提
画面単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページの表示に必要な情報（質問、回答一覧、関連質問一覧など）を１つのエンドポイントがまとめて返してくれるようなものをイメージして言っています。

### メリット
- フロント側は単に表示だけしていれば良く、バック側にビジネスロジックをすべて寄せることができる（あるとしても表示に関するフォーマットのロジックを持つくらい）

### デメリット
- 画面側の表示項目に変更が発生した場合など、API側の改修も必要になる
- APIが画面に依存するかたちになる
- 画面毎にAPIを叩く必要があるので、リソース単位のレスポンスと違って、既に取得済みのAPIレスポンスを使い回すことが出来ない
- ビジネスロジックがバックとフロントの両方に散らばってしまうことになる（フロント側に関しては、フロント側の各画面でビジネスロジックが散らばらないように、store側にビジネスロジックを寄せることで、複数の画面に同じロジックが散らばることは避けられる）
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、似たような情報を含んだ情報を返すAPIエンドポイントが増えて気持ち悪い気がする
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、APIエンドポイントが増えがち
- クライアントがブラウザー、アプリ、CLIと複数ある場合、クライアント毎に表示する情報が異なると思われるので、さらにAPIエンドポイントが増える

## リソース単位のAPIエンドポイントを用意する場合
### 前提
リソース単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページに対応した質問情報を返すエンドポイントがあったり、回答一覧を返すエンドポイントがあったり、関連した質問情報を返すエンドポイントがそれぞれ存在しているようなものをイメージしています。

### メリット
- 画面側の表示項目に変更が発生した場合、フロントが既にバックから受け取っているデータを用いて、計算、加工することでAPIの改修が不要になることもある
- 既に取得済みのAPIレスポンスをキャッシュして使い回すことができる場合がある（キャッシュして問題ないものに限る）

### デメリット
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？ 改めて、ビジネスロジックとは何かの定義と具体例を挙げて、検討した方が良さそう）

## リソース単位のAPIエンドポイントと画面単位のAPIエンドポイントの両方を用意する？？？
メリデリ挙げてみて、両方のパターンの組み合わせを用意するのはどうなのだろうと思いつきました。
こういうのって、実際、やってたりするのでしょうか？

例えば、リソース単位のAPIを叩くのを基本としつつも、そのAPIでは取得出来ない画面固有の差分を取得するAPIエンドポイントを別途用意するみたいなイメージです。

## よくわかっていないけど、BFF ???
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報をまとめたレスポンスを返すAPIエンドポイントをBFFに用意する？

SPA開発におけるAPI設計ってどういうものが好ましいのでしょうか？

### 異なるトランザクションでのEntity更新処理によるロストアップデート？の対策

※DBの想定としてはMySQLでデフォルトのRepeatable Readです。
質問内容
・複数のリクエストでほぼ同時にEntityを取得し、それぞれ更新処理をする際にロストアップデートが起きるのではないか

例：銀行口座に50万円があったとして、ほぼ同時に
1. 口座の持ち主が30万円引き出す。
2. 銀行が40万円の自動振替を行う
を行った場合に、異なるトランザクションで口座残高が50万円のEntityが2つ作成され
それぞれEntityへの操作を行うことで口座残高が変更されたEntityがRepositoryを介してDBに保存されます。
この時に期待する処理は上記２つの処理が直列的に実行され、自動振替を行う際に残高がマイナスになりエラーが発生することです。

ですが2つの処理は同時に残高50万円の状態のEntityを保持しているため、更新時には
1.残高20万円で保存される
2.残高10万円で保存される
となり元々ある残高以上の取引が行われてしまい、最終的に残高10万円でDBに保存されてしまいます。

### 考えた対策
口座を更新する際には排他ロックをかけることで複数のリクエストに参照させないことで防ぐことができると思うのですが、ロックすることで待機時間が増えてしまうということもあり他の方法を考えています。

他に方法があれば教えていただきたいです。
よろしくお願いします。



異なるトランザクションでのEntity更新処理によるデータ不整合の対策

# 聞きたいこと
SpringBootを用いてドメイン駆動開発の学習をしているのですが、ドメインとドメインの外のやり取りがしっくりこないので皆さんの意見を聞きたいです。  
詳細は以下の通りです。

### 1. DB(Repository)とドメインの連携について
ドメイン駆動が、ドメインの開発に注力する為のものであるとはいえ、Webアプリケーションである場合、全体としてドメイン表現のDB永続化や逆に復元についても考える必要があります。
SpringではよくJPA(Hibernate)を使用しRepository経由でDBとのやり取りを行うかと思いますが、ここにドメインモデルの概念を導入すると、以下のオブジェクト間でデータ変換が必要になります。  

- ドメイン駆動におけるエンティティや値オブジェクト
- JPA利用の為に使用する@Entity(データクラス)  
(CQRSの様にクエリー結果格納用のDTOを作る場合も基本的には同様)

具体的にはFactoryやConvertクラスを作ることになり、単純ではあるものの初期実装コストはかりますし、その後の機能追加でも大抵の場合一緒に修正が必要になるかと思っています。  
ここで疑問なのは以下の通りです。


- **ドメイン外の変換クラスの実装・管理コストは許容するしかないのでしょうか？**※1    
- **ドメインオブジェクト ⇔ DTO間の変換に伴い、ドメインにただのgetterを生やす必要ができてしまう(DTO -> ドメインはファクトリで何とかなる)がこれも仕方がないのか、それともリフレクション等で対応するのが一般的なのでしょうか？**
- **トランザクションスクリプトと比べると、上記コストはかなり無駄が多いといった所感ですが、ドメイン駆動で開発している方もこのあたりの認識は変わらないのでしょうか？**※2

※1 ドメイン駆動開発により、ドメインロジックとそのデータをドメインパッケージに凝集する事は成功しているので、それらを技術的な側面に適合させる為のコストを払うのは仕方ないという考え？
※2 トランザクションスクリプトによる開発のメリットであるともいえる?

### 2. クライアントとの連携について
RESTサービスにする場合、前述1項のDBの件と同様にjsonへの変換コストが発生するかと思います。  
@JsonPropertyで対応できない事も無いですが、json構造の設計自由度は下がるのでやはりDBと同様に変換用のConvertクラスとDTOが必要になると考えています。

- **こちらも同様にドメイン外の実装コストは払うほかないでしょうか？**
※ページ(html)を返却する場合は、比較的簡単かと思います。

### 3. そもそもSpringMVCとドメイン駆動の相性が悪い
Springは開発者をビジネスロジックの開発に集中できるようにするアーキテクチャになっていたと思うので、勝手にドメイン駆動開発に適していると思い込んでいましたが、そもそもこれが誤りでしょうか？

つまり、ドメイン駆動開発の様なオブジェクト指向をフル活用しているデータとその振る舞いを表現する様な設計はそもそも想定していないのでしょうか？
(Springにおける開発は、ビジネスロジックに集中するとは言っても、データクラスとロジックのみを扱う@Serviceクラスで分けて表現するという思想？)

### 追記
回答頂いた後も学習を続けた結果、「ドメイン駆動設計」の捉え方が悪かったかもしれないと気づきました。
エヴァンス本スタートだったので、同書籍で紹介されているようなエンティティや値オブジェクト等の形を意識しすぎていた。  
現在は、あくまでドメイン駆動の本質は以下の点であるという考え方に変わった。  

- ドメイン層といったレイヤーを作り、ここにビジネスモデル(ロジック)を閉じ込める
- 技術や他システム間(DB、外部API等)のやり取りロジックは、ドメイン層以外の上位層(外側)で吸収する (※1)
- 各レイヤーの依存方向をドメイン層に向ける

※1：ここでいう"技術"はWebであればリクエスト/レスポンスのようなもののことであり、仮にビジネスのコアになるような技術ならドメイン層にすることもある。

以上から、別にドメイン層の設計を必ずエンティティや値オブジェクトの様に表現しなければならないというわけでもない。
その為、ドメイン駆動であってもドメイン層がデータ中心なアプローチで手続き的になる事もあり得る。
(勿論、データとロジックをカプセル化するオブジェクト指向的なものが、ドメイン駆動の説明にマッチしているとは思いますが...)

ちょっと頭が固すぎました^ ^

ドメイン駆動とSpringBootの相性について

## 様々な条件があるクーポンのドメインモデリング

注文情報・顧客情報・期間限定セールなどに応じて
・注文全体への割引
・特定の商品への割引
・特定のカテゴリ（ブランド）への割引
・割引ではなく、固定金額になる。（クーポンを使うと200円など）
・送料無料
・回数制限
など

ドメインを跨いで影響する様々な仕様を持つクーポンと注文クラスについてのドメインモデリングについて

他の方がどのようにクラスを実装するか、お聞きしたいです。

## 状況
特に既存のシステムがあるわけではなく、注文と注文に対して使用できるクーポンがある場合にどのようにモデリングしたらいいだろうという意見交換です。

#### 概要
・OrderクラスはCouponの配列を持ったImmutableなクラス。
・OrderDetailクラスは商品情報を持った注文詳細クラス（各注文商品の金額を持つ）
・CouponクラスはCouponInterfaceを使用することで、様々な仕様のクーポン機能が可能

Orderクラス
```php
<?php
namespace App\Beer;

use App\Beer\Interface\CouponInterface;

class Order {

    private ?int $id;

    private int $price;

    private Customer $customer;

    private OrderDetails $orderDetails;

    private Coupons $coupons;

    private DeliveryFee $deliveryFee;

    public function __construct(
        ?int $id,
        int $price,
        Customer $customer,
        OrderDetails $orderDetails,
        Coupons $coupons,
        DeliveryFee $deliveryFee,
    ) {
        $this->id = $id;
        $this->price = $price;
        $this->customer = $customer;
        $this->orderDetails = $orderDetails;
        $this->coupons = $coupons;
        $this->deliveryFee = $deliveryFee;
    }

    public function getId(): ?int {
        return $this->id;
    }

    public function getPrice():int {
        return $this->price;
    }

    public function getTotalPrice():int {
        return $this->price + $this->getDeliveryFee()->getValue();
    }

    public function getCustomer():Customer {
        return $this->customer;
    }

    public function getOrderDetails(): OrderDetails {
        return $this->orderDetails;
    }

    public function getCoupons():Coupons {
        return $this->coupons;
    }

    public function getDeliveryFee():DeliveryFee {
        return $this->deliveryFee;
    }

    public function addCoupon(CouponInterface $coupon) {
        $this->coupons = $this->coupons->addCoupon($coupon);
    }

    public function addOrderDetail(OrderDetail $orderDetail) {
        $this->orderDetails->addOrderDetail($orderDetail);
    }

    public function hasProduct(Product $product):bool {
        return $this->orderDetails->hasProduct($product);
    }
}
```
OrderDomainService
```php
<?php
namespace App\Beer\DomainService;

use App\Beer\Coupons;
use App\Beer\Order;
use App\Beer\Interface\CouponInterface;

class OrderDomainService {

    public function __construct(
        
    ) {
        
    }

    public function couponIsApplicable(Order $order, CouponInterface $coupon):bool {
        // TODO:: すでに適用されているクーポンとの状況も確認する必要がある
    
        return $coupon->isApplicable($order);
    }

    public function applyCoupon(Order $order, CouponInterface $coupon): Order {
        $order->addCoupon($coupon);

        $appliedOrder = $this->calculateCouponsOrder($order);

        return $appliedOrder;
    }

    private function calculateCouponsOrder(Order $order):Order {
        $orders = [];
        $coupons = $order->getCoupons()->asArray();

        $combinations = $this->permutation($coupons);
        // クーポンの適用順で最も最小金額になる組み合わせを探す
        foreach ($combinations as $coupons) {
            $couponCollection = new Coupons($coupons);
            $appliedOrder = $couponCollection->apply($order);
            $orders[] = $appliedOrder;
        }
        // 最小注文金額のOrderを返す
        $minTotalPriceOrder = $this->getMinTotalPriceOrder($orders);

        return $minTotalPriceOrder;
    }

    private function getMinTotalPriceOrder(Array $orders):Order {
        $totalPrices = [];
        foreach($orders as $order) {
            $totalPrices[] = $order->getTotalPrice();
        }

        $minTotalPriceIndex = array_keys($totalPrices, min($totalPrices))[0];

        return $orders[$minTotalPriceIndex];
    }

    // 本来は渡された配列の順列を返す
    private function permutation(array $arr): array {
        return [
            [$arr[0],$arr[1]],
            [$arr[1],$arr[0]],
        ];
    }
}
```
Couponsクラス
```php
<?php
namespace App\Beer;

use App\Beer\Interface\CouponInterface;

class Coupons {

    private Array $coupons;

    public function __construct(
        Array $coupons,
    ) {
        $this->coupons = $coupons;
    }

    public function asArray():Array {
        return $this->coupons;
    }

    public function addCoupon(CouponInterface $coupon):self {
        $this->coupons[] = $coupon;

        return new Coupons($this->coupons);
    }

    public function apply(Order $order): Order {
        foreach($this->coupons as $coupon) {
            $order = $coupon->apply($order);
        }

        return $order;
    }
}
```

ProductCouponクラス
```php
<?php
namespace App\Beer;

use App\Beer\Enums\CouponTarget;
use App\Beer\Enums\DiscountType;
use App\Beer\Interface\CouponInterface;

class ProductCoupon implements CouponInterface {

    private String $couponCode;

    private int $specificPrice;

    private Product $product;

    public function __construct(
        String $couponCode,
        int $specificPrice,
        Product $product
    ) {
        $this->couponCode = $couponCode;
        $this->specificPrice = $specificPrice;
        $this->product = $product;
    }

    public function isApplicable(Order $order): bool {
        return $order->hasProduct($this->product);
    }

    public function apply(Order $order):Order {
        $appliedOrderDetails = [];
        foreach($order->getOrderDetails()->asArray() as $orderDetail) {
            if ($orderDetail->getProduct()->getProductCode() == $this->product->getProductCode()) {
                $appliedOrderDetail = new OrderDetail(
                    $orderDetail->getId(),
                    $this->specificPrice,
                    $this->product,
                );
                $appliedOrderDetails[] = $appliedOrderDetail;
            } else {
                $appliedOrderDetails[] = $orderDetail;
            }
        }
        $orderDetails = new OrderDetails($appliedOrderDetails);

        $appliedOrder = new Order(
            $order->getId(),
            $orderDetails->getTotalPrice(),
            $order->getCustomer(),
            $orderDetails,
            $order->getCoupons(),
            $order->getDeliveryFee(),
        );

        return $appliedOrder;
    }

    public function getCouponTarget(CouponTarget $couponTarget): CouponTarget
    {
        return CouponTarget::PRODUCT_CODE;
    }

    public function getDiscountType(DiscountType $discountType): DiscountType
    {
        return DiscountType::SPECIFIC_PRICE;
    }
}
```

CouponInterface
```php
<?php
namespace App\Beer\Interface;

use App\Beer\Enums\CouponTarget;
use App\Beer\Enums\DiscountType;
use App\Beer\Order;

interface CouponInterface {

    public function isApplicable(Order $order): bool;

    public function apply(Order $order):Order;

    public function getCouponTarget(CouponTarget $couponTarget):CouponTarget;

    public function getDiscountType(DiscountType $discountType):DiscountType;
    
}
```

### 聴きたい意見
#### クーポンの割引の適用処理をOrderクラスで行うべきか、OrderDomainServiceで行うべきか

Orderクラスからクーポンの適用処理を行おうとすると、金額を変更したOrderDetailや DeliveryFeeを持ったOrderクラス（自分自身）を返す必要があり、不自然な処理になっている気がします。

一方、OrderDomainServiceにOrderとCouponクラスを渡し、割引が適用されたOrderクラスを受け取るようにすると
適用処理はDomainServiceに任せているのに、Orderはどのクーポンが適用されているか把握する必要があるためCoupon配列を持っているという違和感を感じます。

現状、OrderDomainServiceで実装する方が良いと考えていますが、他の方法も含めて意見を聴きたいです。


注文とクーポンのドメインモデリングについて

## テーマ、知りたいこと

なぜ特にＭＶＣフレームワークなどで、サーバーはステートレスが原則なのに動的クラスを使うんでしょうか？

## 背景、状況

サーバーはステートレスで状態を持たないにもかかわらず、クラスになっているのか分からないです。
modelはstaticなのも多いですが、コントローラーやサービスクラスが動的なのはどうしてですか？
全部静的クラスでいいのではないでしょうか。
もしかしてＤＩなどをやる都合でしょうか？

オブジェクトが状態を保持していい事あるのでしょうか。

諸兄のご意見を伺いたく存じます。
