スポンサードリンク
ＤＤＤ
ドメイン駆動設計の勉強会に参加しました
目次
私の思い
昨今の状況
昨今の大規模開発でトラブルをいろいろ見てきて正直辛い思いをしている
１２兆円の技術的負債損失もその一部
根本的に何か変えないともう立ち行かなくなる
その一貫として、プロジェクトマネジメント技法を学んできましたがそれだけでは足りない
今あるものを再構築するには修正のしやすさと柔軟に成長が可能な仕組みが必要と痛感していたところです
アジャイル型開発もあるけど
今あるものの再構築には不足してる気がしてる
その時に出会ったのがＤＤＤ
今回の講演者のひとりである増田さんの話を聞き
本を読み自分なりの仮説を立てた
そして参加です
講演内容
私が参加した講演から気になったことをまとめています
はじめに
経済産業省のDXレポート
レガシーシステムの課題、技術的負債の問題
ブラックボックス化
変更が難しい
ちゃんと設計しよう
ドメイン駆動設計が対応方法の一つ
現場のドロドロ感を共有する
ソフトウェアの核心にある複雑さに立ち向かう
いつも困ってて苦闘しながらやってきた結果で
もっといい効果が出るんじゃないかと思ってることを伝える
苦労の割には成果が出ていない感もある
核心にある複雑さに立ち向かう
メリハリが必要
素早く最初の一歩を踏み出したソフトウェア
セカンドバージョンが失敗する
ドメインロジックの設計と改良を重視
これが狙い
ドメインモデルに基づくエンタープライズシステムの開発
モデルから切り離された実装、レガシー化
どう進化、成長させていくかが狙い
変更を楽で安全にする
最新の技術を使ってもレガシーになる
怖くて触れなくなる
レガシーはもうたくさん
変更がやっかいで危険は全てマイナスに働く
ソフトウェアの核心にある複雑さ
一つを解決したらいいのではない
ドメインはユーザの活動、ビジネスそのもの
ドメインの複雑さのソフトウェア表現
コード全体の一部
→ここが核心
ドメインロジックとはビジネスルール
ビジネスの概念 表現する語彙
ビジネスの状況 元になる事実
ビジネスルール ロジック
複雑になる理由
ビジネスルールを適用する条件による分岐
ここを捉えると安心につながる
関心の分離、モジュール構造の工夫
ドメインロジック ビジネスルール
ドメインモデル 計算モデル
オブジェクト指向 型指向のプログラミング
→手応えを感じてるやり方
言葉の理解を合わせる
ドメインエキスパートは理解しているが、
それを間違えないように理解できる仕組みを作る
ドメインエキスパートを探す
いない場合もある、自らなることも必要
ビジネスルールの記述を隔離する、まとめる
そして整理する
トランザクションスクリプト系 レガシー
ビジネスルールが断片化、重複する
特に判定が重複する 変更がやっかい
入出力の関心と計算を分離する
意識的に忘れる、項目やDBなどを忘れる
計算や判定のロジックをオブジェクトとしてとらえる
型指向、独自のクラスを定義する
大きなポイント！ intである必要なし
数値、日付などをビジネスルールに合わせて型を作る
カプセル化、ポリモーフィズム、継承
fact rule goal の型を作る
深いモデルを探求する
ビジネスルールの中核を見つけて中核に集中する
俯瞰的に整理する
最初は見つからない、段階的に発見していく
暗黙的な概念をなんとか言語化し
言語化されたもの、コードの表現力を改善する
蒸留 見定めていく
中核を見定めて中核に集中する
断片化、重複してるものをぬきだす、まとめる
→進化と成長を続けるソフトウェアを手に入れる
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート
PHPやってたらDDDチームへ
抽象的なフレーズがわからん
君のドメイン層からは業務を感じないと言われる、、、泣
名詞の抽出をやってみた
ただの箱になった、箱同士の線が引けない
ドメインに集めたが、、、
リポジトリの引数が多くて雑多
テストコード書くのがすごく大変
動詞を探してみた voidの排除も
イン、ロジック、アウトの形で無理矢理にでも整理
それから絵を描く
リターンするクラスが必要だが、文章にある単語とは限らない
→テスト実行早い！いろいろ分かった！
ドメインか否かの境界
ドメインの中にも境界があるのでは
依存を断つ、依存している線を逆にした
依存が少ない、安心して変更できる
ドメインとテーブルは同じペースでは育たない
設計人材を育てるために DDD をどう使うべきか？
良い設計は人が作る、人が育てる
自分が設計できるのとメンバーが設計できるようになるは違う
balusというシステムで独立
案の定、複雑化
終わらないリファクタリング
みんなで設計できるように
やらせてみる、できない、負のスパイラル
設計と実装のスキルは違う
DDDを使って設計力を育てられないか？
さまざまな抽象度でモデルが必要になる
プロセス全体がモデル
ドメインモデルはシステムの外（ユーザーの関心）とシステムの中をつなぐ
ドメインモデルは実装と無理なくつながる
ドメインモデルで議論する
意外とできない、、、
責務の分割と組み合わせは設計の基礎となる力
見えてこないときは視点を変える
全体が連動する
設計は一方通行ではない
問いかけで師匠の当たり前を弟子の当たり前にしていく
要望対応を題材にして教育した
コミュニケーションとりながら
ドメインモデル上で議論
別の視点との行き来
問いかけ大事
成果物のみでは難しい、プロセス重要
どこから作ってどこから変えて行くのかを悩んでいる
時間の変化についての議論が漏れがち
設計力をどう測るかはこれから
QualityとDeliveryを両立させるために僕らがやったこと
〜トラベルシステムの技術全面刷新〜
制約の中、Quality高いものを作り維持し続けること
設計の工夫
コンセプト
UI/UXとAPIをきれいな状態で保つ
現行、、、、webにビジネスロジック、APIは重複たくさん
ビジネスロジックをドメイン単位に抽出して対応しようとしたが、、、webとAPIで乖離していた
間に層を入れた
最初にデータを整理するのはリスク
データはそのままに層を間に入れて対応
チームも分けている
web.API.DATAの３層から８層に変更
API層の対応について
対象を決めて
現行の関心ごとを各自理解
チームの言語基盤を作る
骨格を説明する 論理的に説明できるように
モデルと実装をひもつける
ハマったこと
付け焼き刃では無理
難しい業務
モチベーション、向き不向きあり
登り方の工夫
一括全面一新はやらなかった
スモールスタート、段階的に
システム視点と保守視点で品質をチェック
ハマったこと
暗中模索
仕様書なし
新しいことやりたくなる
暗中模索対策として、中心的に進める人には壁打ち役を置く
仕様書なしはDDDで書き起こすチャンスと考えた
新しいことはスモールスタートなので基本的なこと+3までにした
これから考えていること
きれいを維持する
WG、ガイドラインの作成
対応コスト対応
重要コンポーネントは完璧に
それ以外は効率的に
KPI貢献度と保守コストで判断
システムに組織を合わせたい（逆コンウェイ)
システムにあった組織に再編成
非エンジニアへの伝え方
ビジネスメリット・実績値で語る
承認を取るのはスモールスタート前と、残りの前
実績値は刷新前後で比較した→工期が短くなった
開発効率をサービスの巡航速度として報告
ドメイン駆動設計とマイクロサービス
入稿システムは
ページ指定、パラメータでコンテンツを返す
モダンなシステム開発を目指して最初はデータモデルを作る
サービス構成として４つ
、、、マイクロサービス？分けただけ？
回収範囲が広い、レガシー化してる！
ビジネスとサービスの不一致が原因！
マイクロサービスの切り方が良くない
ドメイン駆動設計の発想、手法に着目
コンテキストと境界を探る
集約を見つける
データ視点からビジネス視点に
ドメイン駆動設計を始めてみた
モデリングでユーザーの関心を設計
テーブルについては頭から外した
新しい関心ごとが見えた
ビジネスも常に成長途中
モデルの明確化をフォローしていく
ドメイン駆動設計がシステムを守ってくれている
壊すのもエンジニア、守るのもエンジニア
難しさ
理解を得難い
複数チームだと難しい
初期実装コストが高い
ドメインを守るのが大変 レビューなど
段階をふんで対応していく
ビジネスルールの複雑さに立ち向かう実践技法
ビジネスの俯瞰と詳細
ソフトウェアか現実かの４事象で考える
掘り下げる、広げる
良い設計をするには知識、スキルが必要
インプットを少しずつ増やすだけでいい
値オブジェクト３種
fact
ビジネスとして適切な値の範囲を定義する
rule
計算ロジック、判定ロジックを記述する
goal
結果の返す
暗黙の概念を制約にする
型を作っておけば境界値テストが要らなくなる
区分を列挙し１モジュールでやってみようとすると、整理できる
ビジネスルールを俯瞰して整理する
ポリシー、契約、運用、能力
業務知識を学ぶ
マーケットでの競争地位
リーダー、チャレンジャー、フォロワー、ニッチャ
４Ｃ理論
など
パネルディスカッション
１．興味を持たないメンバーにはどうすればいいか
コーディングからの学びから始めていった
契約
人は選ばないといけないかも
いきなり言い出さない方がいいかも
２．作業見積について
DDDだからではないのでは？
やったことのないことを見積のは無理だけど慣れればできるようになるはず
３．ユビキタス言語の管理方法
開発側も運用側でもどんどん言語が誕生するので悩んでる
挙げたけど使い切れていない
使い切れないとディレクションの人が必要になる
仕様を取り違えそうなものは作る方法もあり
４．テストコードはどうしているか
スクリプト言語だとテストが増える
型に変えるとそれが不要になるのでテストコードは減った
設計で品質を確保する
自分でテストするのも大事
５．DDDでなくてもいいじゃんと言われたら？
変更で困ることが減ることにメリットを感じるかどうか
DDDではなくシステム構築ポリシーとして伝える
２割の壁を越えると導入できる
まとめ
感想
発表者各々の個性と経験が伝わってきた
200人越えの参加者
悩んでる人が多いんだろうな
自分は言語寄りではないのでわからない言葉もあったけど
設計やロジックについては理解できた
レガシーシステムは言語ではなく
やり方で作られる
ビジネス視点、ユーザー視点、価値
視野を広げよう
段階をふんで対応していく
暗黙の概念を制約にする
ドメインエキスパートを探す。自らなる
コードより、マネジメントや業務知識の方が得意な
自分としての直接的な悩み解決のきっかけは
ビジネスルールの４事象と逆コンウェイの法則が出てきた
参加者の方のブログなど
気がついたものからリンクしておきます
たくさんあります！
トゲッター ボリュームあり。定期的に見直したい
