Skip to content

Latest commit

 

History

History
50 lines (40 loc) · 2.59 KB

part1.md

File metadata and controls

50 lines (40 loc) · 2.59 KB

PART1 ドメインモデルを機能させる

DDDの前提 

  • イテレーティブな開発
  • ドメインエキスパートとの協業
  • ソフトウェア開発ではドメインとドメインロジックが一番大事
  • ドメインの設計はモデルに基づく

ソフトウェア開発の複雑さの根本 → ドメインそのもの、技術的なものではない


モデルの有用性

  • モデルと実装(設計)が相互に形成し合う モデルを実装し、実装のフィードバックをモデルに反映
    モデルの理解に基づいてコードを解釈できるようになると保守性UP
    → XXXXXのコードを読んでも全く業務理解ができないのはモデルと実装が乖離してるから
     (例)エンティティに処理が全くないetc

  • モデルはチームが使用する言語の基盤になる 誤:XXXXが、、、
    正:受注情報が、、、
    (XXさんも言ってた)

  • 蒸留された知識
    フィードバックループによってドメインの最も関心のある要素を際立たせる


ソフトウェアの確信

ソフトウェアの核心はドメインに関係した問題を解決する能力
有能な開発者は技術領域を優先しがちだが、ソフトウェアはドメインの問題を解決するもの!!!!

題名のソフトウェアの核心にある複雑さに立ち向かう
→ ドメインに存在する問題の複雑さに、ドメインモデルを活用することで対処する


まとめ

  • ソフトウェアの役割はドメインの問題を解決すること
    -> FWが、、とかシステムアーキが、、とかはドメインの問題を解決するための手段にすぎない
  • ドメインモデリングは大事  ー>エンジニアは技術勉強だけでなくドメインの勉強をすべき

疑問点、議論したいこと

  • ドメインの分析とかは、スクラムやリーンXPでは誰がどのフェーズでやるのか? いてレーティブにやると言っても、ある程度最初にやらないときつそう

  • リーンXPのユーザストーリやスクラムのスプリントレビューでは、開発者がモデルをどう捉えているか というより、ソフトウェアの機能がどうかという議論がされると思う
    → POやPMがメインなのか?,モデルのフィードバックループは具体的にどう回すのか

  • XXXXXで本当のDDDを取り入れるには何が足りないのか、どうすべきなのか?