見出し画像
Photo by peishum

「ライブモデリングとコーディングで理解するDDD」参加してきました

脱脂綿

この勉強会に参加してきたので、聞きながら取ったメモをoutputです。

アーカイブが残されているようなので、このブログだけ読むくらいならアーカイブも見に行っておくべきかと思います（

期待したこと

- 久々のDDD勉強会で、DDDの知識を再確認する
- ライブモデリングとコーディングという実践のやり方を間近にみる

前段の説明に取ったメモ

- 原点はここ
　- https://www.domainlanguage.com/ddd/reference/

- DDDのモデリングから得られる利益
　- ドメインの何らかの問題を解決できる -> 機能性
　- 長期的に問題を解決し続けられる -> 保守性
　- DDDの目的はこのふたつ

- 機能性向上へのアプローチ
　- 役に立つものになる可能性を高めたいから、ドメインモデルという抽象化物にドメインの知識を反映する
　- 各フェーズで得られた発見をこまめにフィードバックする

- 保守性向上へのアプローチ
　- 頻繁なモデルの更新に耐えられるためのデザインパターン

- 2つのアプローチはドメインモデルでつながっており、一緒に適用するとより大きな価値を発揮する
　- 片方だけでも悪くはない、恐れるな

- DDDにおけるモデリング
　- モデリング手法は具体的に定められているものはない
　- 最もミニマムで効果が出しやすいのがsudoモデリング
　　- システム関連図 system
　　- ユースケース図 usecase
　　- ドメインモデル図 domain model
　　- オブジェクト図 object

ライブモデリング中に取ったメモ

- システム関連図
　- 開発するシステムと、関わりあるアクターや外部システムとの関連を示す図
　- この時に仕様も仮置レベルで決めておく（ex.システム対象外を決める）
　- アクターとシステムをプロットして、アクターの関心事や必要な仕様を並べることができる

- ユースケース図
　- ○○という前提で開発進めていく、ということを3ヶ月後にひっくり返されるより、ユースケース図を作った時点では未定にしておいて、ドメインエキスパートに確認していく
　- 書いている途中に気付いた事を1度遡って話をしてよい　行ったり来たり
　- この際ミニマムな機能範囲を絞り込む

- ドメインモデル図/オブジェクト図
　- ユースケースに登場する言葉から具体的なものを描いて図にしていく
　　- 松岡流は緑背景で具体的なものを描く
　　- ex. 応募者氏名：松岡 / 応募経路：リファラル / ...
　- 具体的なものから抽象的な概念を取り出してオブジェクト図にしていく
　　- 抽象的な概念を取り出した結果違和感に気付いたら、具体の図も修正していく
　　- ここで見つけた違和感で修正された言葉は全部の図で修正していく、これがユビキタス言語
　　　- モデルで作ったものこそがユビキタス言語
　　　- ユビキタス言語を先に揃えるのはやり辛いし、単語帳はメンテされなくなってしまうから、モデルをマスタにしていく
　- オブジェクトの関連が見えたらそこに各オブジェクトの持つ制約を併記する
　　- 持てる状態の範囲
　　- 1:N、1:1といった多重度の関係も記載する
　　　- 0になることもある、みたいな重要な話も
　- 集約の範囲を決める
　　- 集約は実装の話だから、ドメインエキスパートは巻き込まなくて良い
　　- Repositoryの単位の話である
　　- この単位でしか出し入れできない、と決めておく事で得られる恩恵がある -> 前の動画を参照
　- モデルの英訳を決めておく
　　- 別コンポーネント間（フロントとサーバーみたいな）の齟齬を防ぐ
　　- 英語と日本語のセットがユビキタス言語である

- モデリングはぬるっと始める
　- 要件についての話をしている間に「議事録取りますね」という具合にぬるっと

- 未定のことも「未定であること」を図に落としていく
　- 決まっていないこと、途中のことを表すことが重要

ライブコーディング中に取ったメモ

- 常に我々の成果物は仮説である　という意識を持つ
　- DDD以前のアジャイルのプラクティス
　- 時間掛けて作ったモデルでちゃんと実装できるかは分からない
　- 実装した結果をモデルにフィードバックしていくことが必要
　- そのため一番シンプルなモデルをサーバーからフロント含めて動作させることを最初に手を付ける

- 悪い例から改善の例
　- UseCaseクラスの中でドメインオブジェクトのパラメータを参照して処理を分岐させているパターン
　- ソースコードを書いてからレビューする際に「ドメインルールがどの層のコードに現れているか」という観点を持つことで防ぐ事ができる
　- ドメインルールをドメイン層に移して、ユースケースでそれを呼び出す
　- 制約違反にならないように、ドメインオブジェクトのプロパティはprivateにして守っている
　- そうすればテストコードはドメインルール部分を手厚く書けば良い

- モデルからコードに「そのまま落とし込む」のが重要
　- 1回目の実装は良いかもしれないが、変更があった時にモデルの変更を実装のどこに反映すればいいのか分からなくなる
　- 結果として反映する先が間違っていたら、余計にモデルから乖離していく原因になる

FAQのメモ

- モデル図のメンテ
　- ユースケース図のメンテは不要、作り捨て
　- 他は保守する効果が高い

- DDDの始め方、取り入れ方
　- 個人的に、担当している1機能から始める事ができる
　- トップダウンで進めれば期待効果は大だが、チームの合意を取って実装コストも増す

- ActiveRecordパターンを中心に据えたFWでDDDやるには？
　- 真面目にやるならRepositoryの中に全部閉じ込めて、ドメイン層ではModelを使わない
　　- その形ならActiveRecord関係なくなる
　　- ただFW機能使えてないよね
　- RepositoryでActiveRecordをラップするのもあり
　　- 「集約」は表現し辛い

- データベース先行で考えてしまうのをどうすればドメインルールを考えられるか？
　- DBをNoSQLでやる、という前提で考えてみる

- 実際に手を動かす勉強法
　- ToDoアプリみたいなシンプルなものを題材にするのでもOK
　- モデル図の吹き出しに何も出てこないとツラミ

聞いた後の感想

期待した実践部分までかなり詳細に知る事が出来たのが良かった。

またモデリングと実装コードで動画にされていた部分はこの本でも読めるということで、復習を兼ねて読みたい。

語られる内容は本でも纏まっていたようだが、ライブモデリング・ライブコーディングということで作っていく手順とその作業中に考えていることが語られていたのがとても勉強になった。
知識と実践の間の部分はやはり実践している所を横目でみるのが良い。

あとこれらのツイート（とスレッド）を覚えておきたいと思った。

次回は11/13にDDDのテストコードについて話をするらしい。Go Conferenceの終盤と被っててconnpassの参加申し込みが出来ないのだが、アーカイブを見ようと思う。


この記事が気に入ったらサポートをしてみませんか？