DDD Alliance での発表内容。イベント参加者に事前記入してもらった質問や意見への私からの回答

1. 現場で役立つ
システム設計の原則
～変更を楽で安全にするオブジェクト指向の実践技法
DDD Alliance
2017年8月30日
増田 亨

2. よせられた質問やコメント（抜粋）
• テストについて、もっと書いてほしかった
• ドメイン駆動設計の Entity/Aggregate/Factoryは？
• サービスの固有名詞はユビキタス言語になりえるか？
• プレゼンテーション層の文言をドメインモデルに？
• メッセージの国際化
• update文を使わない理由
• すべてのカラムがNot Nullは、非現実的では？
• Rest APIは分割のし過ぎ？
• 受託開発でドメインエキスパートと会話できるケースが少ない

3. いくつかの回答
• テストコード
• 自分はめったに書かない（ミニフレームワーク開発の時くらい）
• 実データ、実画面での動作確認はこまめにやっている
• 経験的な品質保証
• プログラムの構造による品質保証
• プログラムの記述のわかりやすさによる品質保証
• Entity, Aggregate, Repository, Factory, …
• DDD本の解説書の意図はなかった（橋渡しは意識した）
• 手続き型の発想で解釈をしている人も多いので、書き方が難しい

4. いくつかの回答
• サービス名の固有名詞はユビキタス言語の一部になるか？
• コードの意図の説明に有効ならそのまま使う
• 語呂合わせ的な名前であれば、それを説明する言葉に置き換える
• 文字列表現はプレゼンテーション層の関心事では？
• ドメイン層に持ってきたほうが、説明が明確になることが多い
• Bean Validationのmessage属性（エラーの説明）
• 状態の区分名( 未読、既読、保留など）
• オブジェクトの文字列表現は、オブジェクトの重要なふるまい
• 例えば、LocalDate.parse(“2017-08-30”), LocalDate#toString()
• メッセージの国際化
• 今の自分たちには必要ない
• 後から messages.propertiesに外だししても、それほどたいへんではない
（構造的な変更ではないので不安定にならない）

5. いくつかの回答
• SQL update文
• 集合の考え方として update は違和感がある
• delete / insert は実装が簡単 （対象がなくても、追記できる）
• すべてのカラムが Not Null は非現実的？
• 実際にやっている
• 特に困っていない
• SQL のスキル＋ IDE サポート
• Rest API は分割のし過ぎでは？
• 意味のある最小単位の発見が、プログラムを安定させる
• 修正や拡張を（安定した）最小単位の組み合わせ方の変更にしたい

6. いくつかの回答
• 受託開発の現場で、ドメインエキスパートとの会話は現実的に
は難しい
• サービス会社の内製でもたいへん
• エキスパート（経験者）とかいない場合も多い
• 一般に話を聞きたいエキスパートほど忙しい
• 説明が上手とは限らない
• 開発者が積極的に学ぶ
• それも開発の仕事の一部
• 画面、データ、マニュアル、ガイドブック、…
• 触りたくなるソフトウェアを早く提供して、フィードバックをもらう
• まちがい／見落としを早く発見する

7. 本の内容について、あなたの実践状況はいかがでしょうか？
合計：121 人
20.7
52.0
24.0
3.3
同じようなことを既に実践している
今後、実践していく予定
今後、実践してみたいがうちの現場では無理そう。。。
実践できそうもない

8. 導入の悩み
• 徐々に実践しているが、なかなか効果が見えてこない
• 全体を組み立てたサンプルコードが欲しい
• 新規でないと難しいのでは？
• まわりの理解・協力が得るのが難しい/時間がかかる
• 意思統一が難しい
• 既存のアーキテクチャ／フレームワークとの違いが大きすぎる
• データベース中心の開発チーム
• 自分のスキル不足、理解不足
• スケジュール、予算
サンプルコード: github : isolating-the-domain

9. 私がこころがけていること
• 小さな実験を習慣にする
• 失敗することも多い
• 失敗するから実験
• 失敗体験は財産
• やりすぎてみる
• 境界値を具体的に知る最善の方法
• 境界値（と思っていたこと）を超えた時に何が起きるか確かめる
• 最初は（安全な）sandbox 環境で思う存分
• ある程度の見通しがたったら production コードで慎重に

10. 私がこころがけていること
• 時間はかかる
• 小分けにして
• 少しずつ
• とにもかくにも自分がすこしずつ変わる
• 自分の変化をコードで測定する
• 自分が書くコードに起きる変化
• 他人のコードを自分が読むときの変化
• 自分のコードを他人が読んだときの変化
• 現場で頼られる存在を目指す
• 公式の役職・役割ではなく、現場の実質的なリーダー
• 頼られるほど、裁量範囲が広くなる

11. どこまで自分の裁量でできそうですか？
• 変数名の変更
• 段落に分ける
• 説明用変数の導入
• メソッドに抽出
• クラスに抽出
• 値オブジェクト
• コレクションオブジェクト
• 区分オブジェクト
• パッケージの名前変更
• パッケージ構造の変更
• アーキテクチャ／フレームワークの変更
• 設計スタイルの変更