DDD本 4章：ドメインを隔離する
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

- https://discordapp.com/channels/432531367427964929/740202765619429487/764416283831042058

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。
- 共感したものに:+1:を付けたい(また、付けられてるとも思う)が、全体で議論するほどでもない場合に迷ってしまうことがあります。

---

# 第2部 序章
## 目安の時間
- 18分

## 感想・気づき

- P.62「ドメイン駆動設計のプロセスを回復力のあるものにするためには、開発者は広く知られた基本原則が、モデル駆動設計をどのように支えているかを理解する必要がある」:+1:
- :memo: 「回復力」＝ドメイン駆動設計開発に軌道修正する力
- :memo: 原文「To make the domain-driven design process resilient, developers need to understand how the well-known fundamentals support MODEL-DRIVEN DESIGN, so they can compromise without derailing.」回復力 = resilient
- :memo: 元に戻ろうとする力
- :memo: 正しい設計であり続ける力
- :memo: プロセスが正しくあり続けることですね。
- :memo: ・ able to recover quickly after something unpleasant such as shock, injury, etc.
・ returning to its original shape after being bent, stretched, or pressed
後者の意味が近そうな印象
- :memo: カウボーイになるなよってイメージ
- :memo: 現実には教科書どおりにはならないのでちょいちょい妥協しつつ、妥協したままではなく本筋に戻る、戻ろうとする力学を「回復力 = resilient」と表現しているのかなと
- P.63 のナビゲーションマップを読むと、モデル駆動設計を構成している要素を俯瞰して見やすくてよかった。先にこれを見てから、第3章のモデル駆動設計の節読んでもよかったのかもしれない:+1::+1::+1::+1::+1:
　　- :memo: ナビゲーションマップが本の始めと最後にも載っている
　　- :memo: ドメイン駆動設計をあらわすモデルですね。
　　- :memo: そして個々の用語と矢印は、ドメイン駆動設計を記述するユビキタス言語でもある、と言えそう :+1:
　　- :memo: 本文中でも、4章から3つの章は「パターン・ランゲージ」として構成されている、という言及もありましたね
　　- :memo: 「用語」ではなく「言語」というのが、改めてひしひしと伝わる(図の下に「モデル駆動設計を構成する言語のナビゲーションマップ」と書かれている)
- p.62「優れたドメインモデルを開発することは芸術である」、この表現を見て、ドメインモデルに正解はないし、試行錯誤し続けるしかないというのをエヴァンスが示唆しているのを感じた:+1:
- :memo: 建築は芸術ですよ。建築からパタンが来ているので、繋がりはありますよ
- :memo: 素人にはその美しさがわからない
- :memo: 人間の創造性の上に成り立つものである、的な 本性として、作業たり得ない
- :memo: 「しかし、モデルの個々の要素を実際に設計し、実装することは、比較的体系立てて行える。」⇒体系立てて学ぶことができるのでは
- :memo: 「Developing a good domain model is an art. But the practical design and implementation of a model’s individual elements can be relatively systematic.」
- :memo: 「実際に設計し」と訳してるけど、「実践的な設計と、モデルの個々の要素」について relatively systematic と言ってるように見える
- :memo: 設計者の世界観の表現でもあるから、思想的創造物的な感じある。
- P.62「たとえ現実がひどいものでも…」あぁっ!
- オブジェクト指向入門、実践UMLこれまた重いものを紹介するな
- 「開発者は広く知られた基本原則が、モデル駆動設計をどのように支えているかを理解する必要がある。それによって道を外れることなく、折衷案を考え出すことができるのだ。」
- 経験の浅い自分としては、DDDのお手本通りにやりたい気持ちが強いが、どうしても現実と衝突するシーンがある。「折衷案」という言葉が、それを物語っているように感じた。
- *これから3つの章の内容は、「パターン・ランゲージ」として構成されており、そこでは、モデルの僅かな違いと設計における意思決定が、ドメイン駆動設計のプロセスにどれほど影響を与えるかが示される (p.62)*
- 次ページの図だったり、表紙裏の図だったり、参考文献の先頭がアレグザンダーだったり、改めて影響が強いなあという感想
- 個々の内容だけに注目するのでなく、「全体としてどのように繋がっているのか」に注目するのも大切そう

## 疑問

- 【あとでやります！！！】最近、オブジェクト指向ってなんですか?と質問されたのですが、何と回答したら正解ですか?:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- アランケイのメッセージ指向(Smalltalk)?
- ビャーネ・ストラウストラップのクラス指向(C++)?
- バートランドメイヤーのインターフェース指向(Java/C#/Rust)?
- Selfから始まったプロトタイプベース(Self/Javascript)?
- 「あなたのオブジェクト指向はどこから？」でスタートするのが良いかも()
- :memo: クリーク！クリーク！クリーク！
- :memo: 「さあ、あなたはどうだと思います？」「では、考えてみましょう」で、オレは部屋を後にします。（全力逃亡
- :memo: しかし、回り込まれた
- :memo: 「なぜオブジェクト指向で作るのか」の本を渡しましょうw
- :memo: とりあえず「どのオブジェクト指向ですか？」って返したい
- :memo: 「種類あるの？」であれば「なるほどそこからですね」となるので、重要な情報
- :memo: なぜオブジェクト指向で作るのか？
オブジェクト指向しか知らないから
- :memo: でも、まじめなはなし、俺の中ではメッセージパッシングだろうか抽象データ型だろうがオブジェクト指向はオブジェクト指向としての前提は同じだと思ってますけどね。
- :memo: クラス指向とインターフェイス指向に大した違いなんかないよ…
- :memo: アラン・ケイのメッセージパッシングは「徹底的な遅延」が発想の元なので、独自の知識構造を事前に定義可能にする方に注目した（と解釈している）スラウストラップ、メイヤーとは方向が違う気がします
- :memo: オブジェクト指向で解決したい課題が人それぞれなので、OOPの特徴点もそれぞれ違うのかなーという印象
- :memo: 岸田さん(kisさん)が「”現代のオブジェクト指向”なんてないよ。オブジェクト指向入門以降更新されてないし」って言うてたような…。(そっから決着つけるとか正しいとか考えなく成った)
- :memo: if文を減らすテクニックの集合体
- :memo: でもそれだと関数型言語とかも含んでしまうような
- :memo: 私の場合、オブジェクト指向を知らない人に興味関心を持ってもらうために（if文を減らす〜）使ってます。
- :memo: オブジェクトを中心に設計、実装してれば全部オブジェクト指向ですよ。
- :memo: オブジェクト指向がでる前の時代はどうだったのでしょうか？
- :memo: 構造化プログラミングというものがあってですね
- :memo: オブジェクト指向でなぜつくるのか 第2版に記載あり
- :memo: カプセル化、継承、ポリモーフィズム
- :memo: その 3要件は、C++ のオブジェクト指向ですね。
- :memo: メッセージ指向の文脈であれば、「人間が、より自由に創造的に、自分のためのソフトウェアを構築するためのアイディア」スラウストラップ、メイヤーの文脈であれば、「人間の思想・イメージを、厳密かつ明晰に記述できるようにするためのアイディア」みたいな説明を、自分はするかもしれません。
前者は自由度に、後者は厳密性と明確性に重きをおいているイメージ
- :memo: ケイとかメイヤーの違いって空手で言う極真か和道流かの違いみたいな感じで、大事にしてることとか思想は違うけど空手は空手だよね、みたいな。オブジェクト指向は空手

---

# 第4章 序章
## 目安の時間
- 18分

## 感想・気づき
- P.65「より多くのオブジェクトが入り混じった中から、モデル要素を拾い上げるように強制されることはあってはならない。これは夜空に星座を見つけ出そうとするようなものだ」
- 汚い部屋で探し物をするのは大変なので、レイヤを意識した配置に模様替えしようと思いました。:+1::+1::+1:
- :memo: レイヤだけに限らず。コンテキスト分割とかもそうだし。レイヤより小規模な、モジュール分割全般が、適切に構成されていてほしい。
- :memo: 「なんでここでDBアクセスしてるの？」
「え、できるから……」
「」
- :memo: まあ「既存に合わせて」って言われて既存がバラバラのこともあるしね

## 疑問

---

# レイヤ化アーキテクチャ
## 目安の時間
- 18分

## 感想・気づき

- P.68の表を見ていて、インフラストラクチャ層には「ユーザインタフェースの為のウィジェットなどがある」と記述があり、これが意外だった:+1::+1:
- インフラストラクチャ層と聞くと、データ永続化のことばかりが出ていたので。
- 「ウィジェットなどがある」ではなく「ウィジェット**描画**などがある」なので、ウィジェットのようなコンポーネントのことではなく、スクリーン上へのレンダリングといった描画ルーチンなど、物理表現を行なう機能を指しているのでは。
- :memo: ここ、読取り間違いでは、と思った。「描画」のことなので。
デスクトップアプリとかを考えてみてくださいまし。
- :memo: FW（が推奨してるアーキテクチャや設計）にも良さがあり、DDDとかその他にも良さがあり、それぞれを学ぶのは必要に応じて適切に選択できるためなので、どちらか一方に倒すためのものではないですね。
- :memo: Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastracture layer may also support the pattern of interactions between the four layers through an architectural framework.
- :memo: 「上位のレイヤを支える一般的な技術機能」というのがミソなのかしら
- :memo: Graphic Context を取得して、そこにピクセルを書き込んでいく、みたいなのは、物理的な表現に特化した具体的な実装の詳細なので、インフラ層ですね。
- :memo: インフラ層は永続化専用の層ではなく、技術詳細の層ってイメージですね
- :memo: UIは「ユーザに情報を表示」という責務を負うが、そのための詳細な実装技術はインフラ層に委ねる、みたいな感じかなあと
- :memo: インフラ層は永続化専用の層ではなく、技術詳細の層ってイメージですね
- :memo: インフラ層といえばリポジトリ、リポジトリといえば永続化みたいな議論が多いので、インフラ層 = 永続化と認識しがちかもしれない
- P.68 表を改めて見て、いわゆる良くあるMVCフレームワークを使ったとき、MVCの名前をそのままフォルダやパッケージ名に使ってしまうように知らないうちにに誘導されていることが多くて、それが混乱を招いているんだなということに気が付いた。:+1::+1::+1::+1::+1:
- :memo: Rails や Rails フォローの、CoCを強く前面に押し出したFWだとそこそこ頻繁にｲﾗｯとする
- :memo: MVC フレームワークを使うのは精々 UI 層・コントローラー層なので、それより下は別のプロジェクト（パッケージ？）に分けるのがよいのでは。
- :memo: 「技術コンポーネントによっては、他のレイヤの基本的な機能を直接支援するように設計されたものもあれば」
採用しているアーキテクチャがそれを意図しているならしょうがないんじゃないですか?
- :memo: MVC は、ソフトウェアの内部と外部とのインタラクションのアーキテクチャスタイルだから、内部全部を M とするのはそもそもアレで、内部に適切なアーキテクチャスタイルを適用すべきもの。
なので、それを M と呼んだのは、大変罪深い。
- :memo: わりかし「プロジェクトの最初が勝負」だと思っていたり…。(馬力のあるアーキテクトがテーラリングしてほしいし、オレはしたい)
- :memo: MVC アプリケーション プロジェクトにある Model フォルダーに置くのは ViewModel とかリクエスト・レスポンスのモデルで、もっと中核のモデルは別のプロジェクトに置くかなぁ
- P.71「すなわち、メッセージを**いつ**送信するかは知っているが、それを**どのように**行うかまでは背負い込まないようにするのだ。」
- インフラストラクチャ層の責務が「**どのように**行うか」であるため、アプリケーション層が「**いつ**送信するか」以上の責務を負うことは不適切であることがわかる:+1:
- P.72の「通常は、何らかのかたちのアーキテクチャフレームワークが必要である」
- 最初はフレームワークの学習に費やし、そこからどうドメインモデルを表現できるかどうか模索するという学習曲線みたいな感じしている
- P.72「フレームワークの持つ欠点の多くを避けるためには、万能の解決策を探してはならない」
- どうしても、フレームワークの機能を使わなきゃいけない、となってしまうので、この指針はありがたい。。。:+1::+1::+1::+1::+1:
- :memo: 良いプロダクトを素早く開発するためにFWを使うのであって、FWを使うためにFWを使うわけではないよね、的な
- :memo: みんなでアジャイルという書籍で、目的を見失っている状態を、フレームワークの罠として紹介されてました
- P.71「インフラストラクチャ層は…ドメインについての特定の知識を持っていてはならない」
- やっぱり、DBがドメインの知識を持ってはいけないんだな
- P.72「技術コンポーネントによっては、他のレイヤの基本的な機能を直接支援するように設計されたものもあれば、…」
- 一部機能のサポートはすることは想定しているんだな
- ただ、あくまで一部であり、サポートなんだろうな
- P.73「ドメイン駆動設計が求めるのは、たった1つの特別なレイヤが存在することだけだ」:+1::+1::+1::+1:
- DDDの実装で大切なことって何？と質問されたら、こう答えたい。
- 自分なら、モデルとの同期が大事だと述べた上で、アーキテクチャ面では、ドメイン層の話をするだろうなぁと思いました。
- :memo: なによりもドメイン層が大事
- :memo: エヴァンス「俺はドメイン層の話がしたいの！他は今はいいでしょ！！ドメイン層の話させて！！！」
というオタク仕草と受け取れば、いくらか共感しやすいのでは
- :memo: t_wadaさんが言ってましたが、あとはFowlerよろしくってやつですね
- :memo: プレゼンテーション層とアプリケーション層分けるか的なのは、今日みたこのtweetおもいだしました。レイヤを分けることはドメイン層を隔離するための手段であって、それを目的にするとよくない・原理主義的にこだわるべきではない、という感じなのかも。
https://twitter.com/hiroki_daichi/status/1314757722705862657
- :memo:
https://twitter.com/sugimoto_kei/status/1314843283135184897
- ミニマリズムはメチャクチャ重要だけど大きな制約に見えるのが残念
- 「フレームワークの持つ機能の中で、最も価値のあるものだけを賢明に適用することで、実装とフレームワークの結合度を下げ、後の設計上の意思決定を、より柔軟に行えるようになる。」
- 「フレームワーク＝枠組み」としての意味を思い出すと、制限が掛かってしまうイメージも思い出せる。
- P71「ドメイン層を隔離した状態に保つことさえできれば、どのアプローチでも構わない」フレームワークにふりまわされてこれを見失わないようにしたい。:+1::+1:
- *ドメインモデルに関係するコード全部を1つの層に集中させ、（中略）分離すること。（中略）これによって、モデルは十分豊かで明確になるように進化し、本質的なビジネスの知識をとらえて、それを機能させることができるようになる*:+1:
- 「なぜドメイン層を分離するのか」の回答。
- ドメイン層がそれ自体自律して進化することができるようにする、という目的
- なお、ここでは「インフラストラクチャは詳細」「UIは詳細」というような言及・評価は全くしていない（ドメイン層を隔離する目的しか語っていない）点に、注目したい

## 疑問
- P.68「アプリケーション層　ビジネスの状況を反映する状態は持たないが、ユーザやプログラムが行う作業の進捗を反映する状態を持つことはできる。」の2つの状態の違いってなんでしょうか？状態は全てドメイン層が持つものかと思ってました。if文とかで条件分岐するロジックはアプリケーションが持つという意味？:+1::+1::+1::+1:
- 「全体の処理のうち、1/4が終わったよ」みたいな、ソフトウェア上の都合的な話はアプリケーション層で持たせることができる的な意味で解釈してました(その状態すらビジネス上で重要な意味を持っているのならドメイン層)。:+1:
- :memo: ドメイン層は、ドメインオブジェクトの状態の整合性しか関心が無いから。
- :memo: ドメイン層にアプリケーション層の状態を管理させると、ドメイン層が分厚くなりすぎて密結合になる。分祀しないとアレ。
- :memo: システムコールに対する適切なドメインオブジェクトの利用、
あるいはアプリケーションの状態（≠ドメインオブジェクトの状態）管理
を実施するのがアプリケーション層、みたいなイメージ
- :memo: ViewModel はアプリケーション層以上のレイヤでしょうね。UIのレイヤと言っていいと思う。
- P.68「プロジェクトによっては、ユーザインタフェース層とアプリケーション層を厳密に区別しないこともある。」
- 敢えてそういう構成にするのは、どんなケースなのだろう(アンチパターンだと思っていたので驚いた)。 :+1: :+1::+1::+1::+1::+1::+1::+1:
- :memo: どんなソフトウェアでそういう構成をとるのか？
- :memo: 小規模なソフトウェア。
- :memo: 使い捨てのソフトウェア。
- :memo: プレーンなRails API とか、かなり近いんじゃないですかね
DBからぶっこ抜いて、そのまま返すようなアレ。
- :memo: マスタ系編集とか
- :memo: 過去やってたプロジェクトはUI・アプリ層がごっちゃでした。。。
障害出さないために沢山残業したな（涙）
- :memo: その疑問を書いたのは自分ですが、
ドメイン層は分離しつつも、その2層を混ぜていることが気になっています。
小規模且つ複雑なパターンでしょうか。
- :memo: ここの文脈は特に気にするほどではなくて、4層にわけられるが、必ずしも全部別れていないかもしれない（exプレゼンテーションとアプリケーションを区別せず...）ただし、ドメイン層分かれてなかったらDDDできないからね！
ってエバンスが言ってるだけだと。
- :memo: エヴァンスの意図はわかるのですが、その2層を分けてないことを否定しないのだなぁと
- :memo: ここでのエヴァンスの意図は「ドメイン層を隔離する」ということの正当性を訴えることなので、
それ以外については簡単にまとめているだけじゃないですかね
- :memo: 厳密に議論したら、両者は常に分けるべき（あるいは分けないべき、分けても良いし分けなくても良い、どれか）になるかもだけど、
そこをここで深堀りする気は無いだけに見える
- :memo: エヴァンス「いや、まあそこはいいじゃん、それよりさあ！」
- :memo: ViewModel(= アプリケーション層？)がUI操作に対応するドメインオブジェクト操作を定義し
UIがユーザー操作とViewModelのIFをマッピングする、的な
- :memo: アプリケーション層はユースケース層といった方がわかりやすいのでは？
- :memo: このコミュニティ主催の松岡さんの書籍でも、ユースケース層として扱われてましたね
- :memo: ApplicationとUseCaseは厳密には違うけどね
- :memo: 意味が変わっちゃってるので、本当に置換して良いのかなあ、という疑念は正直なところ

---

# ドメイン層はモデルが息づく場所
## 目安の時間
- 18分

## 感想・気づき

- p.73「ドメインの実装を隔離することは、ドメイン駆動設計の必要条件なのだ。」
- ドメインの実装を隔離することは必須だがそれだけでは十分ではない、と読めることに注意を払いたい。
- :memo: エバンス同じ事ばっか言って尺を稼いでる説

## 疑問

---

# 利口なUI「アンチパターン」
## 目安の時間
- 18分

## 感想・気づき

- P.74「単純なプロジェクトはたいていスケジュールが短く、期待も控えめである」
- とてもわかる。。。マスタメンテ画面とかまさにそんな感じ
- P.75「それほど有能でない開発者でも、この方法なら、ほとんど訓練しないで仕事ができる」:+1:
- 未経験を採用するけど、教育に時間を裂けないような企業で、アンチパターンのプログラムが量産されるんだと思った。
- DDDとまで言わず、そもそも設計が疎かにされる根源の一つになっていそう:+1::+1::+1:
- 「仕事ができる（すすめられる）」=有能とは限らない（ぐはっ
- 人を集めやすいという点ではメリット。ソフトウェアの将来性を考えるべきか否か、という判断がちゃんとされていれば・・・。
- p.75「プロトタイプをユーザに公開し、その要望を満たすように製品を変更することで、問題を克服できる」
- 機能検証用に書いた簡易コードがそのまま製品コードに使われてることを後で知り悲しくなるやつですね...:+1::+1:
- 規模の小さいものならば。。。
- 4GL(第四世代言語)、初めて知った
- [“4GL・MML・EUD”は死んだ？それとも生きている？ \| 日経クロステック（xTECH）](https://xtech.nikkei.com/it/article/COLUMN/20071003/283725/)
- 利口なUIも状況によっては認めているところが好印象
- P76.「最初の一歩を試しに踏み出す先が、ドメインモデルを隔離したモデル駆動でなければ、プロジェクトは利口なUIに行き詰まることになるだろう」
- わかりみしかない
- アジャイルでこの部分を間違って理解している人が多い気がするのは気のせいだろうか?:+1::+1:
- 「アプリケーションが複雑で、モデル駆動設計に取り組むつもりなら、歯を食いしばり、必要な専門家をそろえたうえで、利口なUIを避けるべきである」
- この文章出して、上に専門家雇って欲しい
- 草
- 専門家がいない状況からモデル駆動設計に取り組んだ人もいるだろうし、敬意しかない
- 専門家がいないなら自らが専門家になる、くらいの気概を持って臨みたい:+1::+1::+1:

## 疑問

- この章で言いたいこととしては、単純なCRUDのみのシステムでモデル駆動設計をやるのにはコストが高く付くよ、ということ？
- だから、場合によってはスマートUIを選ぶこともある
- 逆に言うと要求を分析している段階で、十分ビジネスロジックが複雑だと感じている場合には、ドメイン層を分離することから始めないと、今後の変更コストが高く付くということを指し示している？:+1:
- 現在、自分が開発に関わっているシステムは明らかに「利口なUI」から始まって変更が加えられ続けていて限界を感じている。モデル駆動設計に持っていくにはやはり全てを書き換えるしか方法がないのだろうか？:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- :memo: 一部のフロントエンドの人たちは「式年遷宮」とか言って、積極的に肯定しそう
- :memo: リライトしてもメンバー一緒だと同じことなるから転職って選択肢のほうがいいかもしれない。
- :memo: 某ボンバーマン(誰)は、RoRアプリのリファクタリング/リストラクチャリングを延々と頑張っているといううわさ
- :memo: 知り合いのリスペクトしてる方は「とにかく、明日からdomainっていうpackage(directory/namespace)を、自分のプロダクトに切ってみ？」って言うてました。
- :memo: 「FWの更新が激しい」
FWにべったり依存しないようにすることで、影響は局所化できるはずです
ここまででもエヴァンスが語ってますよね
- :memo: まあ、ぶっちゃけ困ってなければそのままでも良いですけどね。
- :memo: フロントエンドとかモバイルアプリ は、DBはサーバーにあるのでマイグレーション一切考えなくてよいから書き直せるってのはあるきがする。永続化されたデータがある動いてるものは、リライトかなり厳しいですね。。。
- :memo: 「ストレスを感じている」が「じゃあ、自分たちの理想通りやってみ」ってやったら「できない」ってこともありましたねぇ。（同じメンバーなら…問題
- :memo: 「書き直すことができる」と「書き直すのが良い」との間には、かなりの断絶があるということは主張しておきたい
- :memo: 全然質問の回答じゃないですが、殆どのシステムは利口なUIになっている気がするので、リライトではなく、プログラムを徐々に作り替えていくスキルを身に着けることも悪くないかな、と思っています
- :memo: リファクタリングするよりコピペ量産してでも機能を早く実装する圧力があるとかなんとか
- :memo: エヴァンスがモデリングで語る「だんだんと知識を深めていく」「知識を蒸留する」という態度は、「まっさらから書き直す」というよりは、「少しずつ切り出して改善していく」の方が近いように思いますが、どうなんでしょうね。
- :memo: https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition
- 最近は CQRS など読み書きを分離しようという機運が高まっているが、利口なUI(スマートUI) とモデル駆動設計は2020年現在においても排他的な選択なのだろうか？　:+1::+1::+1::+1::+1:
- :memo: 「利口なUI(スマートUI) 」 is 何を先に揃えて置いた方が、混乱しなさそうな気がする
- :memo: 揃うのかなぁ
- :memo: ここでの文脈でいうと「ドメインを隔離しない」いものといってもいいかも。
- :memo: その疑問は「両立することがあり得る」という示唆、なんでしょうかね。
- :memo: 「UIが少しでも（種類問わず、某かの）ロジックを持つなら、スマートUI」みたいな議論の仕方もたまに見かけるので
- :memo: この「ロジック」というのがビジネスロジックなのか、UI専用のロジックなのかによる気がしますね。
- :memo: スマートUIにするとドメイン知識が流出してしまう、という理由で、両立しないとしているのでは。
- :memo: 「ロジック」というのがビジネスロジックなのか、UI専用のロジックなのかまさにそこで、「ロジック」というものが「ビジネスロジック」とか「業務ロジック」と呼ばれるものしか存在しないかのような語り口をたまに見かけるので、エヴァンスの言う「スマートUI」は、ドメイン知識の流出を批判するために出してるものだよね、というのを確認したい意図です
- :memo: そうですね。まさにその認識で良いと思ってます。
- :memo: 「スマート」が「現代に置いては肯定的な言葉」なので、たちわるいｗ
- :memo: 「賢すぎるUI」くらいの気持ち
- :memo: ここ押したらあそこが赤くなるみたいのはむしろUIにないとダメだしね
- :memo: 業務ロジック(ドメイン)が漏れ出ているUIはNGという理解。つまり、排他的。
- :memo: CQRSが入ったとしてもスマートUIが必要とされる事はないと思います。
- :memo: CQRS の Q は、アプリケーション層の関心なので、つまりドメイン知識は漏れ出さない。という意味では、Q を発行するのは「賢すぎるUI」ではない、と思いました。
- :memo: 「何かしらのロジックがあるか」ではなく「ドメイン知識が流出しているか」が力点なのでQを発行したり、Qを元にUI状態を組み立てるUIは、この意味で「スマート」にはあたらないというイメージ
- P74下から３行目「ドメイン駆動設計が最も効果があるのは、大掛かりなプロジェクトに対してであり」の部分について、DDDが大掛かりなプロジェクトに最も効果があるのか理由がわからなかった。個人的には利口なUIも大掛かりなプロジェクトに向くのではと思いました。:+1::+1:
- 個人的に利口なUIの利点の中でも大掛かりなプロジェクトに対して有効だと思ったモノ
- 「どんな開発者でもほとんど訓練しないで仕事ができる≒要員調達が楽」
- 「納品スケジュールは比較的正確に計画できる≒スケジュール管理が容易」
- 「要求分析が不足していても、その要望を満たすように製品を変更することで克服できる。≒仕様変更に強い」
- ドメインは複雑という話が根本にありましたが、大掛かりでドメインも複雑になりがちな分、柔軟である必要があるからだと思いました。
- ドメインを理解している人がいなくなってしまいそう
- :memo: 「どんな開発者でもほとんど訓練しないで仕事ができる」
どんな開発者でも触れてしまい品質を維持できない
「納品スケジュールは比較的正確に計画できる≒スケジュール管理が容易」
UIごとにロジックを持ち、コピペや整合性を保つのが苦しくなりスケジュールが読みづらい
「要求分析が不足していても、その要望を満たすように製品を変更することで克服できる。≒仕様変更に強い」
上記と同じ理由で仕様変更も大変
と思うので、メリットを感じる事はあまりない気がします。
- :memo: DDDは「変更容易性」と「把握・俯瞰の容易さ」のために(オレは)やってるので、大きいプロジェクトにこそ「それが要るんだろうなぁ」と思うと、自分は「効果がある」はそうだね、と思いました。
- :memo: 規模というより、複雑さで考えるのはわかりやすいかも。業務ルールを見通せない設計だと、一定以上の複雑なアプリケーションは、最終的に訓練してない開発者も訓練してる開発者も、メンテナンスできないものになるのかもなぁと思いました。

---

# その他の隔離
## 目安の時間
- 18分

## 感想・気づき
- 「自分のモデルには完全に統合しきれていないものを扱わなければならないこともあるだろうし、同じドメインに関する別のモデルを使用する他の開発チームにも対応する必要があるだろう。」
- 開発だけに重きを置けば、独自のドメインモデルを守ることだけを考えていれば良いが、その外部の方達とコミュニケーションを取る時に、どちらのユビキタス言語を使用すべきかは悩む(もちろん相手に合わせるのだが)。「どこでも使用できるユビキタス言語」がブレる点。

## 疑問

---