どうも！今日も勉強会に来ています。初めての JJUG ですが、かなり面白いです。 DDD本、読まなきゃーー。。。

終わりました。感想は後ほど。。

コードに語らせるために和智 右桂氏 (グロースエクスパートナーズ株式会社)

• テクノロジーが難しいというわけではなく、業務が難しいことに、実装や設計の難しさの根本がある。
• エンジニアは一般的にテクノロジーに興味はあるが、業務に興味がない人が多い。が、業務はエキサイティングだからエンジニアも業務をしっかりと理解すべき。というメッセージが込められている。

DDDとは

• ドメイン駆動設計、ドメインとは業務である。
• ２００３年の本。JDK 1.4 だったり。Oracle 10g だったり。
• 参考文献から、著者の思考の背景が分かる。デザインパターンや、オブジェクト指向、リファクタリングなどの考え方の延長線上にある
• ソフトウェア開発とは、学習と再構築の過程。
• 学習すべきはお客様の業務、どうしてそういうことをしているのか？
• お客様の言葉で理解するのが大事。ユビキタス言語。
• 再構築：第一歩は、モデルを共有すること。この業務とはこういうものである、を表現されたもの。お客様も自分も分かるもの。
• 手続き型はモデルではない。全体像から、立体的に理解させる。
• 再構築：モデルを元にソフトウェアを作る
• モデルとソフトェアが揃っていると、業務の変化にソフトウェアに追随できる
• ユビキタス言語：チーム内のすべてのコミュニケーションとコードで厳格にその言語を用いる
• モデル駆動設計：ソフトウェアをモデルにそう形で設計する
• モデリングパラダイム：モデルとコードを結びつけるツール。すなわちオブジェクト指向をツールとして使う。
• レイヤ型アーキテクチャ：ドメインレイヤとは、ドメインモデルが息づく場所。レイヤを分けて、ドメインモデルを他のコードと分離する。
• イテレーティブなプロセス：コミュニケーションを通じてモデルは深みを増していく。
• 戦略的設計：システムが巨大化してもモデルは実装と結びついていなければならない
• 第一部読んだら、第三部に飛んで、から第二部や第四部を読むと理解しやすい。

開発の中のDDD

• システムの分析をして機能の階層に分解する。いくつか流儀はあるがDDDだからというものはない。
• 例えば、ユースケース分析。業務フローを元にユースケースを分析
• ユースケース分析で抽象的な概念で、機能の大分類を捉える。
• 機能間の関連の分析および機能ごとの設計、後で境界を切り直すのはかなり大事。あとで、修正することは困難。画面から安易に切ることは出来ない
• 著者エリックの会社のホームページには方法論がまとめられている、Whirlpool。 -http://domainlanguage.com/ddd/whirlpool/
• シナリオから始まる。→モデリングをする、モデルを見てもらう、質問する→サイドリフレッシュする。高速イテレーション、数時間から数日。間違いを犯せ。
• DDDの本質は成長。保守でも適用できる。
• 「実践テスト駆動開発」とか。
• ドメインモデルのための余地を残してあることが重要。レイヤーや境界を分けておく。

手続きからモデル駆動へ

• 完全なモデルを最初から作ることは難しい
• あらゆる機能でDDDが必要というわけではない。「複雑な」「業務」に適用できる。技術面での難易度とは別。
• モデルによって捉えられる知識は「名刺を見つける」ことにとどまらない。ビジネスの活動やルールもドメインにとって中心的。
• 機能をまたいで繰り返し現れる if 文をエンティティへの問い合わせにまとめる。エンティティが単なるビーンではなく、意味のあるモデルになる
• レイヤ化アーキテクチャ重要。ドメインのレイヤを用意しておく。コードだけではなく、ドキュメントもテストも分けておく。
• ユーザーが理解できないモデルを作ってはいけない、それはモデルではない。
• 躓きこそ最大のチャンス。

DDDで実践する時に役に立つ話し加藤 潤一氏 (グリー株式会社)

• GreeChat で適用した。(限定公開) Scala で実装した。実際の経験を元に事例を発表。
• メンバー８人、８ヶ月開発。言語 Scala、スクラム、サブドメイン３、モジュール１７（そこそこ複雑）
• ３日でプロトタイプを作った。ドメイン層は主要なモデルだけ。ストレージ部分は手抜き。
• チームメンバーにDDD経験者は一人だけだったが、メンバーのモチベーションはあった。
• ユビキタス言語と実装をプロトタイプで説明。ドメインモデルの見本でユビキタス言語を共有。
• 大枠のユビキタス言語が共有できたら、プロトタイプを捨てて、新しく作りなおした。
• 実際の開発に入った後は、もっとも重要なモデルをストーリーから探す
• 「会話」とはなにか？「離脱」とはなにか？
• 人によって理解がバラバラなので、ちゃんとすりあわせて行く必要がある。
• 文脈も含めて共有しながら進める
• どっちの理解が正しいのか？という議論がよくあるし、ちゃんとしておかないといけない。
• シナリオ - モデル - 実装 のループ
• レイヤー化アーキテクチャに組み込む
• ほっとくと他の層に侵食される、意識して隔離しないと混乱する
• ActiveRecord ような User.save() とか。「ユーザー」が「セーブする」というのは、ユビキタス言語にあるか？

• 視点が違うが、テーブル設計、スキーマ設計も同じ。

• DDDってぶっちゃけどうよアンケート

• 効果があったか？
• 効果がなかったと答えた人はいなかった。
• エンジニア・非エンジニア間でのコミュニケーションしやすくなった、コンテキストやモデル知識を共有しやすい、ソフトウェアの構造が明確になった、要件と成果物の関係性が明確になった
• 付箋にエンティティを書いてカベに貼って共有しているチームもある
• 実践する苦労はあった？
• 全員がDDDを知っている必要がある（リードできる人がいればいいのでは？）
• シャーディングなどの技術的な問題とリポジトリパターンとの相性が悪い（どこに責務をもたせるかがかなり難しい）
• DDD本が抽象的すぎて実際の設計や実装レベルでどうするかが人によって異なる（DDD自体が概念であるからそんなもん）
• ドメイン・非ドメインコードの区別ができるようになるのに苦労した
• 集約と性能問題のトレードオフが難しい（概念がそもそも大きすぎるから、という視点もある）
• エンティティのIDとDBMSのシーケンスとの相性が悪い（ID生成器を別に作って管理するケースが多い）
• 読書会を実施した効果はあった？
• 輪読形式の読書会はほぼ毎日行った、一部～二部まで
• ユビキタス言語の重要性を理解できた
• 知識に対する共通認識の基盤が作れるという意味で効果あり
• scala-dddbase導入効果は？
• dddを導入するためのフレームワーク。I/Fのみのガワ。お手本的な。
• 開発が楽だった、DDDの考え方が自然と身についた、必要なインターフェイスがあるので独自に増やす必要がなかった
• 「ライフサイクル管理」の考え方が理解し易い
• 次もDDDを採用したいか？
• どちらとも言えないが大多数（が、狙い通り）
• 規模や期間によると思う、ある程度のエッセンスは使っていきたい
• DDDの難しさは？
• ある程度チーム全員がDDDを理解する必要がある
• Quickly だけ読んで理解したつもりになるな
• http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
• エンジニア間、非エンジニア間でのドメイン駆動設計に関する知識の共有
• 同じ言葉でも捉え方は様座mであるため、分かったつもりになり、問題が発生するまで齟齬に気がつかないことがある
• シャーディングといった技術的な問題にぶつかった時に、どのように解決し、妥協するか