---
# System prepended metadata

title: アジェンダ

---

# アジェンダ
- 一章目の疑問点共有 (5分)
- 議論 (25分)
- 二章目の疑問点共有 (5分)
- 議論 (25分)

# 疑問点(一章)
- ドメイン駆動設計ってどんな感じって言われたときに簡単に返したい
知識をコードへ埋め込むことって結局何？

業務の知識をシステムに落とし込む手法がDDDである。
領域を分ける手法も今後書いてある。

ドメインを概念と捉えている

ドメインは問題空間、解決空間に分けられる

境界づけられたコンテキストは解決空間に当たる

- ドメインは「プログラムを適応する対象となる領域」となっているが、境界づけられたコンテキストとはどう違うのか
ほぼ一緒、だけど厳密には違う！


- アプリケーションを実現するパターンとドメイン知識を表現するためのパターンってどんな関係性？
アプリケーション側がドメインを利用するって書いてあるけど、どんな感じで利用するの？

ビジネスルールを集めておくのがドメインの知識を表現するためのパターン

ファクトリとドメインサービスがごっちゃになることがあるかも

3/19 竹内追記
ファクトリはドメイン層の住人。そして、ファクトリーとドメインサービスはほとんど同じものな気がする。
例えば他コンテキストのデータを自コンテキストのモデルに変換するみたいなサービス(腐敗防止層のファザード)は、
ファクトリーでもある。なので、ファクトリーにビジネスロジックを含んでいいかの判断はドメインサービスと同じようになる気がした。
あと、Entityとかがファクトリーメソッドを(ドメインの振る舞いとして)実装することもある。


~~厳密にアプリケーションを実現するためのパターンとドメインの知識を表現すると考えすぎない方が良い。~~
原則には利用する側と知識を表現するものと分けたほうが良い。

- そのそもDDDはどんなシステムに向いているの？
イメージでは短期的な開発や、プロトタイプのような開発には向いてないイメージがある。受託開発に導入するには重すぎるのでは?

それはある

継続的に、長期的に変更があるシステムに強い

使い捨てのコードには向いてないので、今回の場合は使い回せるコードを作っていくので、有用になるはず。

デメリット:
ファイル数が多くなって時間がかかる、設計時間がかかる
戦略的DDDに時間がかかってしまう

# 疑問点(二章)
- 結局値オブジェクトを一言で表すと何？？
システム固有の値を表現するために定義されたオブジェクト

- 値オブジェクトは不変であるために、交換をすることで値を変更することができる。これのメリットはなんだ？
イミュータブルにすることによって、バグを防ぐためなんだろうけど他にメリットは有る？

文字列の内容を変えられることで、直感的な挙動をしない

並列処理しやすい

- phpで実装するときのequalsメソッドのイメージが付きません！
オブジェクトの値の比較をするメソッドになる？
`$obj->firstName === $firstName;`

```
    /**
     * Check if this Email is equivalent to the other one.
     *
     * @param object $object
     * @return boolean
     */
    public function equals(object $object): bool
    {
        if (!is_null($object) && $object instanceof self) {
            return $this->address() === $object->address();
        }

        return false;
    }
```

3/19 竹内追記
多分、下みたいに`===`メソッドの振る舞いを変えるのはPHPではできない?気がした。(やり方知ってたら教えてください！)
```
$fullName = new FullName("山田", "花子");
$$otherFullName = new FullName("山田", "太郎");
$fullName === $otherFullName;
```
また、できたとしても、混乱を招きそうなので、equalsメソッド作った方がいい気もする。
あと念の為書くと、`$obj->firstName === $firstName;`だとよくない。
理由として、equalsメソッドは値オブジェクト同士を等価判定する必要があるため。
上記の式は、きっとstringと値オブジェクトを判定する式?なので、値オブジェクトの等価判定はできてない。



- 値オブジェクトにする基準は？
値オブジェクトの性質
・不変である
・交換が可能である
・等価性によって比較される

「そこにルールが存在しているか」
「それ単体で取り扱いたいか」
で基準を作る。

ドメインによって判断することや、SOLIDの原則のによって判断することもある。


# 反省点&良かった点

- 👎 質問する人の好みで疑問点を書いちゃうからムラがでそう
- 👍 輪読とはどうやって進めるべきなのかを理解できた
- 👎 あって話した方がやりやすそう
- 👎 マイクが全然繋がらなくて、全員に無視されてる状態になった。正直、寂しかった。
- 👎　議論のスコープ絞った方が良さそう = 質問絞る
- 👎 今後も時間がオーバーしがちになりそう
- 👎 分からないまま話が進むと、間で質問しずらく、最後まで分からないままになってまう。
- 👍 わかってる人がいると、一人で読むより理解が進む。誤解がなくなる
- 👍 楽しかった
- 👍 みんなちゃんと読んできてた
- 👍 楽しかった
- 👍 モチベ上がる

# 次回担当
マギー

3月25日 20時から