Recommended
More Related Content
What's hot
What's hot (20)
Similar to Relationship betweenddd and mvc
Similar to Relationship betweenddd and mvc (20)
More from Takao Tetsuro
More from Takao Tetsuro (20)
Relationship betweenddd and mvc
- 1. DDDとMVCの関係 2 6 t h J u n 2 0 2 1
- 2. 2 PROFILE E n g a g e d w i t h システム構築のプロセス評価、改善、策定、開 発フレームワークの設計、実装管理、プリセー ルスやプロジェクトの立ち上げなど 2 C o m m u n i t y a n d A c t i v i t i e s ブログ ：http://blog.processtune.com プロフィール ：Facebook, Twitter or MVP コミュニティ ：.NETラボの運営スタッフ M i c r o s o f t M V P July 2010 ～ Jun 2022 Current expertise : MVP for Developer Technologies
- 3. MOTIVATION Re a d h i s b l o g STOP doing dogmatic Domain Driven Design M i c r o s o f t M V P for Development Technologies (Canada) H i s a c t i v i t i e s YouTube https://www.youtube.com/channel/UC3RKA4v unFAfrfxiJhPEplw Blog https://codeopinion.com/stop-doing- dogmatic-domain-driven-design/ 3 His YouTube His Blog
- 4. DISCUSSION D o m a i n D r i v e n D e s i g n ユ ニ フ ァ イ ド ・ プ ロ セ ス エ ン テ ィ テ ィ 、 バ リ ュ ー ・ オ ブ ジ ェ ク ト サ ー ビ ス ・ オ ブ ジ ェ ク ト リ ポ ジ ト リ 、 フ ァ ク ト リ ー 、 ア グ リ ゲ ー ト モ デ リ ン グ の 重 要 性 4
- 5. DOMAIN DRIVEN DESIGN O U T L I N E 5
- 7. E R I C E V A N S To develop software for a complex domain, we need to build Ubiquitous Language that embeds domain terminology into the software systems that we build.
- 8. DDDは組織・製品・変更のモデリン グ Methodology・Framework Representative Implementation Modeling tool CQRS (Command Query Responsibility Segregation) Representational State Transfer (REST) Application Programming Interface (API) Swagger YAML Unified Process Rational Unified Process (RUP). Basic Unified Process →Open Unified Process (OpenUP). Agile Unified Process. →Disciplined agile delivery (DAD). Agile Modeling Agile Data Disciplined agile toolkit Just Barely Good Enough (JBGE) Architectural Envisioning Lookahead modeling Active Stakeholder participation Model Storming (JIT modeling) Candidates Responsibilities Collaborators card modeling Responsibility-driven design Domain-driven design Service Oriented Architecture (SOA) Microservices Distributed computing 構築されるシステムの形としては Event driven architecture Distributed system publish-subscribe communication model Service mesh Serverless computing コンテキスト ドメイン モデル ユビキタス言語
- 9. DDDは組織・製品・変更のモデリン グ Methodology・Framework Representative Implementation Modeling tool CQRS (Command Query Responsibility Segregation) Representational State Transfer (REST) Application Programming Interface (API) Swagger YAML Unified Process Rational Unified Process (RUP). Basic Unified Process →Open Unified Process (OpenUP). Agile Unified Process. →Disciplined agile delivery (DAD). Agile Modeling Agile Data Disciplined agile toolkit Just Barely Good Enough (JBGE) Architectural Envisioning Lookahead modeling Active Stakeholder participation Model Storming (JIT modeling) Candidates Responsibilities Collaborators card modeling Responsibility-driven design Domain-driven design Service Oriented Architecture (SOA) Microservices Distributed computing 構築されるシステムの形としては Event driven architecture Distributed system publish-subscribe communication model Service mesh Serverless computing コンテキスト ドメイン モデル ユビキタス言語 やり方 手順 表現方法 （合意形成方法）
- 10. 10 ユニファイド・プロセス Inc e pti o n プ ロ ジ ェ ク ト の 予 備 的 な ス ケ ジ ュ ー ル と コ ス ト の 見 積 も り を 作 成 す る 実 現 可 能 性 を 検 証 す る ソ リ ュ ー シ ョ ン の 調 達 計 画 （ 開 発 、 サ ー ビ ス 購 入 な ど ） El abo rati o n 既 知 の リ ス ク 要 因 に 対 処 す る こ と と 、 シ ス テ ム ア ー キ テ ク チ ャ を 確 立 し て 検 証 す る こ と で す 。 こ の フ ェ ー ズ で 行 わ れ る 一 般 的 な プ ロ セ ス は 、 ユ ー ス ケ ー ス 図 、 コ ン セ プ ト 図 （ 基 本 的 な 表 記 の み の ク ラ ス 図 ） 、 パ ッ ケ ー ジ 図 （ ア ー キ テ ク チ ャ 図 ） の 作 成 で す 。 Co nstruc ti o n シ ス テ ム の 機 能 は 、 短 い 時 間 枠 の イ テ レ ー シ ョ ン で 実 装 さ れ ま す 。 各 イ テ レ ー シ ョ ン の 結 果 、 実 行 可 能 な ソ フ ト ウ ェ ア が リ リ ー ス さ れ ま す 。 構 築 フ ェ ー ズ で は 、 ユ ー ス ケ ー ス を フ ル テ キ ス ト で 書 く の が 通 例 で 、 そ れ ぞ れ が 新 し い イ テ レ ー シ ョ ン の 始 ま り と な り ま す 。 こ の フ ェ ー ズ で 使 用 さ れ る U M L （ U n i f i e d M o d e l i n g L a n g u a g e ） 図 に は 、 ア ク テ ィ ビ テ ィ 図 、 シ ー ケ ン ス 図 、 コ ラ ボ レ ー シ ョ ン 図 、 状 態 遷 移 図 、 相 互 作 用 概 要 図 な ど が あ り ま す 。 Transi ti o n システムがターゲットユーザーにデプロイされます。初期リリース（または初期 リリース）から得られたフィードバックにより、移行フェーズの数回の反復の過 程でさらに改良が加えられることがあります。また、移行フェーズでは、システ ムの変換やユーザーのトレーニングなども行われます。 10
- 11. DEVELOPMENT HISTORY（汎化） 11 Architecture- centric Data Centric Process Centric Component Orientation Executable architecture baseline Unified Process Iterative and incremental development Architecture-centric Risk-focused Agile Unified Process test-driven development (TDD) agile modeling (AM) agile change management database refactoring Disciplined Agile Delivery Agile Unified Process Extreme programming Scrum エンタープライズレ ベル スケーリング Disciplined Agile Toolkit Disciplined Agile 4 Hybrid Six lifecycles Risk-focused Elaboration phase ～2012 2013～ Enterprise Unified Process Productionフェーズ Retirementフェーズ 規律：Operations and Support 規律：その他 組織、企業IT、プロダクト・ ソリューションのライフサ イクル Iterative and incremental development Rapid Application Development Dynamic System Development Method Rational Unified Process Unified ProcessのIBM によるカスタマイズ Open Unified Process Agile approach subset Agile modeling 規律を増やす 規律を減らす 規律を具体化
- 12. DEVELOPMENT HISTORY（特化） 出典：開発のためのCMMI® 1.3版 2010 年 カーネギーメロン大学 翻訳：日本SPIコンソーシアム (JASPIC) CMMI V1.3翻訳研究会
- 13. 開発プロセスの要件、文書、コードの関係 要件 定義 構造要件 機能要件 構造要件 非機能要件 UIフロー（遷移図） View Modelで実装 Code-Behindで実装 視覚要件 Data Access Layerで実装 機能要件 運用手順 機能要件 Controllerで実装 Data Modelで実装 ORマップ
- 14. エンティティ、 バリュー・オブ ジェクト E N T I T Y & V A L U E O B J E C T 14
- 15. MODEL POLIMORFIZM ドメイン サブドメイン バウンデッド・コンテキスト エンティティ バリューオブ ジェクト サービス イベント バウンデッド・コンテキスト … … … … … サブドメイン バウンデッド・コンテキスト エンティティ コンテキスト 固有のエン ティティ インジェク ションによる 亜種モデル … … ユーザー・インターフェイス アプリケーション クラウド・オンプレミス インフラストラクチャ
- 21. サービス・オブ ジェクト S E R V I C E O B J E C T 21
- 23. リポジトリ、 ファクトリー、 アグリゲート R E P O S I T O R Y, F A C T O R Y & A G G R E G AT E 23
- 27. ドメイン アグリゲート REPOSITORY 27 On-premise DB Web API Cloud Repository リポジトリ エンティティ サービス エンティティ サービス バリュー オブジェクト イ ベ ン ト イ ベ ン ト
- 28. 28 モデリングの重要性 組織 マ ー ケ ッ ト の 変 化 が 激 し い 現 代 で は 、 1 年 か け て 要 件 を 詰 め て 、 半 年 間 R F P を 作 成 、 業 者 選 定 、 そ の 後 半 年 か け て 基 本 設 計 、 詳 細 設 計 し て か ら シ ス テ ム 構 築 と 導 入 ・ 試 験 運 用 に 1 年 か か る よ う な プ ロ ジ ェ ク ト 牽 引 は 今 や 少 な い か と 思 い ま す 。 組 織 も 人 事 異 動 で は 賄 い き れ な い マ ー ケ ッ ト へ の 対 応 に は 部 署 の ス ク ラ ッ プ & ビ ル ド 時 に は D D D が 力 を 発 揮 し ま す 。 製品 日 本 で は 、 ア プ リ ケ ー シ ョ ン や サ ー ビ ス を 提 供 す る 企 業 の 多 く が 製 品 戦 略 部 門 と 製 造 部 門 が 縦 割 り に な っ て い ま す 。 ソ フ ト ウ ェ ア の バ ー ジ ョ ニ ン グ と 製 品 の 変 更 管 理 が 連 動 し て い な い ケ ー ス で は 、 ソ フ ト ウ ェ ア の 設 計 の 範 囲 の み が モ デ リ ン グ さ れ て い ま す 。 D D D は ソ フ ト ウ ェ ア の 範 囲 を 超 え た あ ら ゆ る 問 題 解 決 領 域 の 設 計 に 対 応 で き る よ う に 定 義 さ れ て い ま す 。 チーミング 日 本 で は 、 コ ロ ナ 禍 に よ っ て リ モ ー ト ワ ー ク が 急 速 に 浸 透 し た こ と で デ ジ タ ル ・ ト ラ ン ス フ ォ ー メ ー シ ョ ン が 注 目 さ れ ま し た が 、 S t a c k o v e r f l o w な ど で は F u l l リ モ ー ト ワ ー ク の 開 発 者 募 集 を 行 っ て い る 企 業 情 報 を 頻 繁 に 配 信 し て い ま す 。 D D D で は S p o t i f y m o d e l と い う の が 有 名 で す 。 ソフトウェア ソフトウェアの変更管理、展開と拡張戦略まで対応できるDDDは、これまでの 設計手法と相反するものではなく、さまざまな開発者に有用です。 28
- 33. DDDのMODEL DRIVEN例 33 マイクロサービス Models モデル駆動 プラットフォー ム非依存 Swagger yaml Swagger.io Visual Studio でClassにコピペ C# Convert JSON to POJO Objects in Java OnlineでJavaオブジェクトに変換
- 34. CONCLUSION 問題解決領域 ドメインは複数の問題解決領域で 構成される 問題が解決したら、新たな価値が 創出されるのだから、新たな問題 解決領域が発生するほうが自然 問題解決領域とは、運用や手作業、 RPAを含めたソフトウェアとして のソリューション範囲を超えた製 品戦略や組織改編も解決すべき領 域のこと 道具に捉われない 実装パターンよりもコンテキスト が精緻に分析・設計されているこ とが重要 アプローチは柔軟に選択、変化す ることを前提に、チーム全員が成 長することが重要 ステート管理をするのはステート チャート図だというような固定観 念は捨てるべき。ステートチャー トが描ける人はホワイトボードの 手書きの図でもステート管理を完 璧に網羅できる アジャイル アジャイルは設計のあらゆる場面で意 識する必要があり、文書を書くからア ジャイルでないとか、CRCカードを使 わないと設計できないということはな い プロジェクトの牽引手法を選ぶことが アジャイルではない。Kanbanボードを 使ったプロジェクトがすべてアジャイ ルというわけではない。 ユーザーストーリーを深くイマジネー ションすることはアジャイルに有効。 34
- 35. THANK YOU U b i q u i t o u s L a n g u a g e h t t p s : / / m a r t i n f o w l e r . c o m / b l i k i / U b i q u i t o u s L a n g u a g e . h t m l D o m a i n D r i v e n D e s i g n h t t p s : / / m a r t i n f o w l e r . c o m / b l i k i / D o m a i n D r i v e n D e s i g n . h t m l P a t t e r n s o f E n t e r p r i s e A p p l i c a t i o n A r c h i t e c t u r e h t t p s : / / m a r t i n f o w l e r . c o m / b o o k s / e a a . h t m l L i n k s
- 36. THANK YOU L i n k s Domain-driven design : Wikipedia https://en.wikipedia.org/wiki/Domain-driven_design エリック・エヴァンスのドメイン駆動設計 : 書籍 https://www.shoeisha.co.jp/book/detail/9784798121963 Unified Process : Wikipedia https://en.wikipedia.org/wiki/Unified_Process Enterprise Unified Process : Wikipedia https://en.wikipedia.org/wiki/Enterprise_Unified_Process CMMI for Development, Version 1.3 : Carnegie Mellon University https://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15287.pdf DDDSample https://github.com/citerus/dddsample-core Rebecca Wirfs-Brock さんインタビュー( 前編 ) https://www.ogis-ri.co.jp/otc/hiroba/specials/Rebecca/interview1.html
- 37. THANK YOU L i n k s Domain Driven Design https://domaindrivendesign.org/ Design a DDD-oriented microservice https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented- microservice ドメイン駆動設計・開発の実践 https://www.infoq.com/jp/articles/ddd-in-practice/
Editor's Notes
- Domain Driven Designは（複雑な）ドメインの設計のための設計手法です。名前が長いのでDDDと言わせてもらいます。 DDD設計プロセスにおけるエンティティ、バリュー・オブジェクト、アグリゲート、サービス、リポジトリ、ファクトリーをすべて実装することは必ずしも正ではありません。複雑ではないドメインにおいて要素が省略された設計はDDD設計プロセスではないというわけではありません。また、DDDは複雑なドメインモデルに対してのみ採用すべきという考え方も特定のシーンでは正解ですが、日本の多くのプロジェクトにおいては正解ではありませんので、本日はそのあたりの話をきっかけにしてモデリングの重要性をお話ししたいと思います。 このセッションではユニファイドプロセスからDDD設計プロセスまで通ずるモデリングと、どのようにDDD設計プロセスの要素省略を行うのかをさまざまなドメインパターンを例に解説します。
- 読む
- 本日のお話をなぜ行おうと思ったのか？というモチベーションとしては、カナダのMVPのデレクさんのブログ「CodeOpinion」を読んだからです。非常に面白い内容で「独断的なドメイン・ドリブン・デザインをやめよう」という内容です。彼は「ドメインのモデリング、境界線の定義、そしてそれらの関係性は、Repositoryパターンを正しく使用しているかどうかを気にするよりもはるかに重要です。」と語っており、まさに私が実務で感じていることをそっくり言い当てていたからです。私はDDD自体は意識してはやってこなかったのでサブドメインの境界線定義とサービス設計を解説することはありませんでした。ただし、モデリングの重要性は.NETラボでもMicrosoft 365 Virtual Marathonでも話してきたつもりです。また、ユーザーストーリーごとに設計・構築するマイクロサービスにおいて、まさにサブドメインの境界線定義とサービス設計は行っており、よくよく考えると古くからあるユニファイドプロセスやMVCとDDDは異なる設計を言及しているのではなく、ユニファイドプロセスやMVCの外側にあるものも含めて設計することを訴求していることを理解しました。 日本の多くのプロジェクトにおいて…とお話したのは、その部分についてです。ちなみに彼はもっとシンプルに複雑さは大きさからくる複雑さも含まれるため、複雑なドメインモデルに対してのみDDDが役立つわけではないと訴求しています。
- 本セッションのアジェンダです。まずはDDD設計手法の概念をお話しします。そのあとに、この概念がマイクロサービスを始めとする進化変化するドメインモデルのソリューションに親和性が高いことを解説します。なぜ親和性が高いのかは、この概念の中心にある戦略的デザインの各要素を理解できると明らかになりますので、先にDDDとユニファイドプロセスの成果物の関係をお話しして、どのように補完し、MVCにどのように貢献するのかをお話しします。そしてDDDの各要素を軽くお話しして、モデリングの重要性にまとめようと思っています。
- DDDは、オブジェクト指向のコミュニティに根差しているエリック・エヴァンスが説いた概念です。なのでユニファイドプロセスやMVCでの設計と相反する概念ではありません。バズワードのようにアジャイルやなんとか駆動という言葉が使われていますが、その後ろにある知識を持っているかどうかでプロジェクトの成功の可否が決まります。 DDDは、ドメインのオブジェクトを考えるときに、いずれのプログラミング言語や図式化された表記法に当てはまらない概念としてエンティティ、バリュー・オブジェクト、サービス・オブジェクトの分類とアグリゲートという概念として理解できることをマーチン・ファウラーが説いています。これらの要素で表現できる「境界を持つコンテキスト」のネットワークでドメインを表現する戦略的デザインという考え方が中心になります。
- DDDのモデリングというのは、企業の組織改編を含む製品戦略や問題解決領域、それらの変更を含む継続的インテグレーションのモデリングを指します。エリック・エヴァンスの本から入ると敷居が高いかもしれませんので、こちらのDomain Driven Designのサイトから入るとスムーズにDDDの世界に入れるかと思います。このサイトのAbout usのところに書いてある文言です。ここでいうプロジェクトマネージャーがいればその人が行うこととして書かれているのがDDDになります。なので、本来は開発者のコミュニティでお話しする
- 複雑なドメインのソフトウェアを開発するためには、ドメイン用語をソフトウェアシステムに埋め込むユビキタス言語を構築する必要があります。
- まずDDD設計において最も重要なことをお話しします。あらゆる設計手法は設計そのものとその設計結果をどのようなプロセスで文書化するかということは分けて規約化されています。DDD設計手法ではこのような内容について設計するということが取り決められており、それをどのようなプロセスでどのような記法で描くということはあまり重要ではありません。
- 責任駆動設計の提唱者であるレベッカワーフスブロックさんは日本で多くもてはやされているBCE：boundary(システム外部との境界), control(制御を行う), entity(情報を保持する)やロバストネス分析はアメリカではあまり使われていないと言っています（https://www.ogis-ri.co.jp/otc/hiroba/specials/Rebecca/interview1.html）。作成するシステムから入る日本のアプローチと異なり、要件からユースケースを分析し作成するソリューションを設計するアメリカとの違いです。例えばいくつかの日本の大手メーカーは自社製品をどのように導入するかに関心があり、プロダクションエキスパートが多いのですが、自社製品がソリューションのどの部分を問題解決できるのか？を設計するソリューションアーキテクトが少ないということです。
- まずは、なぜDDDが必要なのかを考えるために UPの規律は、Business Modeling、Requirements、Analysis and Design、Implementation、Test、Deployment それに加えRUPの規律はConfiguration and Change Management、Project Management、Environment AUPの規律は、Model、Implementation、Test、Deployment、Configuration Management、Project Management、Environment 図の規律のその他とは、Enterprise Business Modeling、Portfolio Management、Enterprise Architecture、Strategic Reuse、People Management、Enterprise Administration、Software Process Improvementを指しています。 図のSix lifecyclesとは以下の6つのライフサイクルを指します。 The Agile Life Cycle: A Scrum-based Project Life Cycle The Lean Life Cycle: A Kanban-based Project Life Cycle The Continuous Delivery:Agile Life Cycle The Continuous Delivery:Lean Life Cycle The Exploratory (Lean Startup) Life Cycle The Program Life Cycle for a Team of Teams
- CMMIは特定の業種に対して繰り返し開発プロセスの改善を行っていき、この業種の開発はにはベストなプロセスを構築することを目標としています。 図はカーネギーメロン大学の図を日本SPIコンソーシアムが翻訳したものですが、現在リンクが切れていますのでカーネギーメロン大学の原文へのリンクを巻末に記載してあります。
- これは、私が2012～2014年によく使っていたユニファイドプロセスにおける成果物の連続性を訴求したスライドです。主に開発者が先行文書との連続性のないドキュメントを記述し、マネージャーが設計に関して丸投げしていたことが多かったので開発の範囲で訴求していました。そのためMVVM実装パターンでのインプリメンテーションまで言及しています。 このころのユニファイドプロセスでUMLはシステムの形を図式化する有用な記法として一般化しており、現在でもDDDの中でユビキタス言語として使うことができます。マーチン・ファウラーがDDDの解説で言うところの「いずれのプログラミング言語や図式化された表記法に当てはまらない概念」というのは、ユニファイドプロセスが確立された時点ではまだ黎明期であったマイクロサービスや分散コンピューティング、継続的インテグレーションや製品戦略、最近のSpotifyモデルのような組織編成をDDDが包含するため、システムを構築・拡張・縮退することを目的としているUMLでの図式化には、その記法が定義されていないという意味です。 ユニファイドプロセスにおけるIterative and incremental developmentのようなモダンなソリューション・ライフサイクルに対応するためには、構造要件の先にあるデプロイメント図やパッケージング図の詳細が必要になります。これは開発側の関心ごとであって、要件としては定義されないこともあります。また、設立フェーズは記載していませんが、ユニファイドプロセスには設立、コスト見積もり、基本スケジュール、実現可能性、調達などを定義していますので、この開発の側面のみがユニファイドプロセスではないことを理解してください。ユニファイドプロセスをまともに実施できなければ最近の開発プロセスは実施できません。前述したようにモダンな開発プロセスのルーツがユニファイドプロセスであり、それらが簡略化や拡張されてきた歴史があり、その更改の歴史には明確な理由があるからです。 またユニファイドプロセスでは精緻化フェーズ（の入り口）で、ユースケース図、DFD、詳細スケジュールを定義するように訴求されてます。 構築フェーズでは、全ユースケース内の実行可能なソフトウェア単位（場合によっては同じ単位）のイテレーションでアクティビティ図、シーケンス図、コラボレーション図、状態遷移図、相互作用概要図が用意されます。これをふまえ、DDDの各エレメントを見ていきましょう。
- DDDでいうところのドメインモデルは多態性を包含している場合があります。先述のユニファイドプロセスではユースケース図によってそれは明らかになります。アジャイルモデリングなら、ユーザーストーリーやストーリーマップ、データモデルなどからも明らかにすることができます。この部分はドメインエキスパートと相対するプリセールスやプロジェクトマネージャーといった製造チームの上流工程の登場人物によって必ず行われなければいけません。 日本の多くのプロジェクトにおいて複雑なドメインモデルでなくともDDDが有用である理由は、この多態性を無視したままデータベースを先に設計したり、画面をエンドユーザーと詰めたりしている上流工程を行った結果、失敗しているプロジェクトが多いことです。 DDDのドメインモデルの設計アプローチでは、モデルがいくつあるかを明確にするため、工程とリスクの見積もりが明確になります。 モデルがいくつあるかを明確にする方法はバウンデッド・コンテキストと呼ばれるサブドメイン内のモデルを設計する作業になります。サブドメインは複数のバウンデッド・コンテキストがありバウンデッド・コンテキストはエンティティやバリューオブジェクトで表現することで実装につなげます。この際、サービスやイベントもバウンデッド・コンテキストを表現するパターンとして扱われますが、本セッションではモデリングの話が中心になりますので、別の機会にお話ししたいと思います。バウンデッド・コンテキストのエンティティは固有の属性を持つ場合もありますし、インジェクションによりモデルの属性が変化する場合もあります。まずはバウンデッド・コンテキストからお話しします。
- ユーザーストーリーは単一の重複しないシナリオですから、それがいくつか積み上げられてSubdomainが構成されます。ユーザーマップはマトリックスとして縦のユースケース内にユーザーストリーが並べられ、横にプロジェクトのフェーズで切られているだけですので、すべてのユーザーストーリーを列挙できているか？が工程の見積もりを左右しますし、それらのユーザーストーリーをユースケースごとにまとめ、サブドメインとして精緻に構成できるか？がクリティカルチャートのリスクを明確にします。なぜならDDDのモデルは実行可能なモデルである方がアジリティに優れていることは明らかですし、DDDのサブドメインはひとつのリッチドメインモデルで構成されている場合、それをマイクロサービスとして分割でき、固有の永続化層を持たせることができるからです。 そのほかにもデータモデルからの積み上げもアプローチのひとつです。例えば、演奏者の名前はどのシーンでどのように使われるか？を計画することは、そのままユーザーストーリーを“深く”イマジネーションする作業ですし、ユースケースにおけるエンティティのデータバリエーションを計画する作業ですので、サブドメインにおけるバウンデッド・コンテキストの設計のアプローチとして有用です。 DDDはバウンデッド・コンテキストを精緻にモデリングすることを明示しており、どのように精緻化するかに関してはユビキタス言語
- 境界コンテキストのそれぞれのモデルは属性の意味や呼び方が違います。視聴者のみが使用するミュージックプレイヤー・アプリケーションではモデルは一つの形をしているかもしれませんが、そのアプリケーションを配信サービスしている会社が提供する場合、またはその会社が販売店を持つような企業であった場合、さらにランキング情報を提供している場合は、楽曲というモデルが持つ各属性の重要性や意味、属性の個数などが各問題解決領域によって変化します。 DDDが活躍する典型的な複雑なドメインモデルとは、そのようなモデルのことで、それぞれの問題解決領域で境界を持ったBounded Context（境界コンテキスト）が必要になります。それぞれの境界内をSubdomainといいます。Bounded Contextの各属性の他Subdomainとの関係も明示し、かつ処理される順番（納品後発売できる）も定義します。 活躍するというのは、ソースコードを見たときが一番わかりやすいかもしれません。例えばプロジェクト内の発売日のコンテキストはどうなっていますでしょうか？ ReleaseDateやReleaseDateTimeでしょうか？それともDispatchDateTime？BloadcastDate？ProvideDateTime？もしSubdomain内でこんな感じのコンテキストが混在しているソースコードを見たら、そのプロジェクトのマネージメントがうまくいっていないことに気づいてください。あなたがプログラマーならコンテキストの定義を丸投げする上流工程を行うプロジェクトからは早く逃げましょう。あなたが上流工程の人間ならプロジェクトメンバーからあまり仕事ができる人間とは思われていないという自覚を持った方がいいでしょう。 マーチンファウラーが言うところの「モデルを有効に活用するためにはモデルが統一されていること」とはモデルの属性が同じ属性名かまたは他のサブドメインの特定の属性との関係が明示されていることで一意に決めることができるということです。多義的な意味を持つコンテキスト（例えばリリース日）を使わないようにするためにはドメインの中心に向かう属性を決めることが重要です。楽曲を聞けるのはいつか？ということが視聴者にとっての配信日時の意味であり、そのディスクを販売できるのはいつか？というのが販売店にとっての販売開始日です。もしかしたら配信業者にとって、配信日時は契約上の配信解禁日時の意味に業務の関心があるのかもしれません。
- 同じサブドメイン内で同じバウンデッド・コンテキストでも、ユーザーストーリーによっては関心ごとが異なり属性が変化したり増減することがあります。後述するバリューオブジェクトと同じく生存中は不変のバウンデッド・コンテキストを作成するためにダブルディスパッチとしてコンストラクタでDependency Injectionを行うことができます。 ただし、バリューオブジェクトは値を与えることで異なる関心ごとを表現しますので属性は同じです。図を表現するためにはすべての属性を持つモデルが必要になります。 DIの場合、非常に雑に表現するとそれぞれのユースケースで共通する属性以外の属性をオプショナル情報として持つこともできます。 このように任意のサブドメインでバウンデッド・コンテキストを設計する場合に、ユーザーストーリーによって同じオブジェクト（演奏者×曲名は同じ）の異なる側面が必要になる場合に利用します。
- バリューオブジェクトは、モデルから生成されてキーとなる値を与えられることによって異なるオブジェクトを表現する方法です。この場合、ユースケース（単一または複数のユーザーストーリー）に関係なくバウンデッド・コンテキストは同じ属性を持つオブジェクトの属性の中身によって個々のオブジェクトを識別できます。例えば、カラオケアプリケーションとミュージックプレイヤーが別の問題解決領域から提供される場合はバウンデッドコンテキストが異なり、エンティティで表現することができます。これを同じ問題解決領域からサービスしたい場合（カラオケ機能付きミュージックプレイヤーの場合）はバリューオブジェクトで表現することもできます。同じオブジェクトの異なる側面を利用するエンティティ表現のインジェクションとは異なり、同じ属性を持ち与えられた値（この場合演奏者×曲名）によって一意であることが決定できます。 後述するAggregate & Eventでは、レイヤードアーキテクチャにおけるデータアクセスレイヤーなどで型解決する例をご紹介します。データアクセスレイヤーのファサードでパースしたオブジェクトをアプリケーション層に転送する際のORマップによって各サブドメインに転送する方法です。
- バウンデッド・コンテキストを表現するパターンとして最も汎用的なものがエンティティになります。プログラマーの方は最も理解しやすいオブジェクト表現パターンです。簡単に言うとデータを利用時にマッチする情報の塊にするということです。 DDDでは、UIに永続化層からのORマップの結果をエンティティとして直接与えることを避けています。なぜなら、前述のように異なるバウンデッドコンテキストは、異なる意義を持った同じオブジェクトを参照するための文脈や状態の翻訳を行うための手続きをエンティティだけに持たせることはしないからです。オブジェクトの意味を定義づける文脈や状態はエンティティ、バリューオブジェクト、サービス、イベントに振り分け、利用側（多くはUIですが）にアグリゲートを経由して提供します。 文脈や状態の振り分けに有用なのがコンテキストマップです。これはどのような手法を用いて行っても良いのですが、CRC cardやUMLのActivity図でもかまいません。上手く描ける人ならロバストネス図でもよいかもしれません。それらの作業は次の「Aggregate & Event」でお話ししますが、その作業ののちにエンティティが出来上がります。
- バウンデッド・コンテキストを表現するパターンとして最も汎用的なものがエンティティになります。プログラマーの方は最も理解しやすいオブジェクト表現パターンです。簡単に言うとデータを利用時にマッチする情報の塊にするということです。 DDDでは、UIに永続化層からのORマップの結果をエンティティとして直接与えることを避けています。なぜなら、前述のように異なるバウンデッドコンテキストは、異なる意義を持った同じオブジェクトを参照するための文脈や状態の翻訳を行うための手続きをエンティティだけに持たせることはしないからです。オブジェクトの意味を定義づける文脈や状態はエンティティ、バリューオブジェクト、サービス、イベントに振り分け、利用側（多くはUIですが）にアグリゲートを経由して提供します。
- 文脈や状態の振り分けに有用なのがコンテキストマップです。これはどのような手法を用いて行っても良いのですが、CRC cardやUMLのActivity図でもかまいません。上手く描ける人ならロバストネス図でもよいかもしれません。それらの作業は次の「Aggregate & Event」でお話ししますが、その作業ののちにエンティティが出来上がります。
- バウンデッド・コンテキストを表現するパターンとして最も汎用的なものがエンティティになります。プログラマーの方は最も理解しやすいオブジェクト表現パターンです。簡単に言うとデータを利用時にマッチする情報の塊にするということです。 DDDでは、UIに永続化層からのORマップの結果をエンティティとして直接与えることを避けています。なぜなら、前述のように異なるバウンデッドコンテキストは、異なる意義を持った同じオブジェクトを参照するための文脈や状態の翻訳を行うための手続きをエンティティだけに持たせることはしないからです。オブジェクトの意味を定義づける文脈や状態はエンティティ、バリューオブジェクト、サービス、イベントに振り分けます。 この振り分けに有用なのがコンテキストマップです。これはどのような手法を用いて行っても良いのですが、CRC cardやUMLのActivity図でもかまいません。上手く描ける人ならロバストネス図でもよいかもしれません。それらの作業は次の「Aggregate & Event」でお話ししますが、その作業ののちにエンティティが出来上がります。などを使って エンティティに関してはDDDだけで言われていることではなく、多くの設計手法で使われている考え方ですが、DDDに関しては
- エンティティに関してはDDDだけで言われていることではなく、多くの設計手法で使われている考え方ですが、DDDに関しては
- エンティティに関してはDDDだけで言われていることではなく、多くの設計手法で使われている考え方ですが、DDDに関しては
- マーティンファウラーはDDDの解説で、エクストリームプログラミングの推進者であるEric Evansの貢献の大きな意味は、その当時どのように表記すればドメインのモデルを表現できるのかを中心に議論されていたところに、モデリングの前にすでに解決されていることを期待されていた作業（ドメインの専門用語をソフトウェアに組み込むための表現をソリューションの関係者全員に共通した表現として構築すること）を明示したことです。これによってドメインのモデルとその表現であるユビキタス言語は成長していくことが期待でき、また実際に成長していくことが重要です。 このユビキタス言語は構成するプロジェクトメンバーによってはユースケース図やアクティビティ図、相互作用概観図のようなドメイン内のオブジェクト関連を表すUMLかもしれないし、CRCが手書きで描かれたホワイトボードの写真かもしれません。
- ソフトウェアで使用するドメインモデル（ビヘイビアとデータ）をベースに開発者（図の右）とステークホルダ（図の左）が共通のユビキタス言語で定義されます。 厳密な定義を表現するユビキタス言語は暗黙の了解を明示できます。この言語とドメインモデルは理解が進むにつれ成長していきます。なぜなら、ドメインエキスパートは問題解決領域を表現できていないユビキタス言語には追加の表現を要求し、システム構築者は明示しきれていない暗黙の了解が残っているユビキタス言語には追加の表現を追加していくからです。追加の表現はUML図であったりマークダウンであったり、開発者とユーザーが共通に理解できる表現を選びます。
- https://en.wikipedia.org/wiki/Domain-driven_design ソフトウェアで使用するドメインモデル（ビヘイビアとデータ）がベースになっていなければいけない DADの概念ですが、ソリューションは消耗品という概念です。
- SwaggerなどのAPI表現においてはドメインのモデルの管理が重要になります。
- UMLを書くとアジャイルではないというのは嘘。相互作用概観図やアクティビティ図がそのプロジェクト内でユビキタス言語ならば、それはアジャイルであるかどうかという側面とは関係ない。