現場で役立つシステム設計の原則

現場で役立つシステム設計の原則

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