2章 業務知識を発見する
事業の課題
ソフトウェアを開発するのは事業課題を解決するため
ここで言う課題は以下
業務プロセスやワークフローの最適化
手作業の最小化
経営資源(ヒト、モノ、カネ)の管理
意思決定の支援
業務データの管理
事業課題は、下記のレベルがある
事業レベル
顧客の抱える課題の解決
業務領域レベル
教務フローの最適化など、具体的な課題の解決
知識の発見
役立つソフトウェアを設計するには、事業活動について少なくとも基本レベルの知識を把握しておくことが必要
業務エキスパート並の知識は不要で、その人達の考えを理解し、ユビキタス言語で会話することが大事 事業課題と要求事項の背景を理解しないまま、開発したソフトウェアは要求事項をソースコードに「翻訳」したに過ぎない
背景を理解しているからこそ、仕様漏れに気づいたりや将来の要求を見据えて開発することができる
意図の伝達
ソフトウェア開発を成功させるには、開発に関するあらゆる事項について、関係者の間で合意し、整合させることが大事
下記のような伝言ゲームのように断片的かつ、誤った情報が伝わってくる可能性のある状態で開発をしても誤ったソフトウェアが生まれてしまう
https://scrapbox.io/files/68a5c2e534d24722c413bf41.png
ドメイン駆動設計では、業務エキスパートからソフトウェア開発者にユビキタス言語使って伝えられる 業務で使う言葉
ユビキタス言語は業務で使う言葉で、正確で一貫していることが必要で業務ロジックを明確に表現できるようにする
あいまいな言葉も避け、同じ意味を構成する用語の意味は一つでなければならない
一つのユビキタス言語で複数の意味で使うようなことはしない
❌️:ユーザー
⭕️:サイト訪問者、管理者
ここで明確なユビキタス言語を使うようにすることで、エンティティの実装が単純で明確なものになる 業務エキスパートと会話することで、不正確な表現、間違った解釈を検知することができる
ユビキタス言語は要件定義、テスト、各種ドキュメント、ソースコード全てにわたって一貫して利用する
業務活動のモデル
モデルとはなにか
モデルとは、現実のものや出来事を簡略化した表現。特定側面を意図的に強調し、一方で、それ以外の側面を意図的に除外する。モデルはようとをげんていした抽象化です
-- レベッカ・ワーフスブラック
モデルは、現実世界の仕組みがどうなっているかを理解するための作り物
例:地図。道路地図、地形図、世界地図、路線図など
効果的なモデル
モデルには目的があり、目的に沿った内容だけを表現する
例:世界地図に、路線図は不要
解決しようとしている課題をサポートするために、表現する対象が限定されている
モデルは抽象化。抽象化の目的は、対象を曖昧にすることではなく、対象を「きわめて正確に」表現するためのもの
用語集を作る
ユビキタス言語の発見と整理のために用語集を作る
更新は全員で行い、常に最新化されているようにする
用語集は新メンバーが事業活動を学ぶときに参照すべき情報源になる
用語集だけでは、名詞の整理しかできないため、合わせてGherkin記法を使って振る舞いを表現できると良い 振る舞いを表現する際に、適切にユビキタス言語が利用されていると、業務ロジックの把握が捗る