共通認識を得る [ino_h]

1. 何をすればいい？

1.1. To Be Continue ...

1.2. イントロダクションはセミナーで

1.2.1. 細かい部分は記事で

1.2.1.1. マインドは書籍で

1.3. DDD の本質を理解する

1.3.1. 「DDD とは？」へ真剣に向き合う気持ち

1.3.1.1. ただし、DDDをマスターすることが本質ではなく、先に見える思想に目線を向ける

1.4. DDD が難しいと感じている人

1.4.1. エンジニアがわかりやすいところから入る

1.4.1.1. OOP

1.4.1.2. モデリング

1.4.2. ボトムアップドメイン駆動設計

1.4.2.1. 値オブジェクト

1.4.2.1.1. エンティティ

2. なぜ DDD？

2.1. 課題に立ち向かう理由

2.2. プロダクトの経過にともなって人やコストばかり増えてプロダクトが成長しない

2.2.1. プロダクトが成長しない ＝ 事業価値があがらない

2.3. 新しい言語やフレームワークが目まぐるしく変わっていく

2.4. フロントエンドの複雑化に戦いを挑むのは急務

2.4.1. 非同期処理の待ち時間

2.4.2. PWA などによる守備範囲の増加

3. DDD とは？

3.1. わくわくする夢物語を描く

3.2. Domain Driven Design

3.2.1. 業務領域駆動設計

3.3. 概要

3.3.1. 事業価値に重きを置く

3.3.1.1. お客さんと議論、傾聴を繰り返し、ビジネスを考える

3.3.1.2. 機能を分割して作るのではなく、コアな部分を最初に抑える

3.3.2. 業務的な戦略の問題領域を正しく見極め、様々なアーキテクチャの戦術により解決へと導いていく

3.3.3. 戦略的設計

3.3.3.1. 問題領域

3.3.3.2. チームで使うパターン

3.3.3.2.1. ユビキタス言語

3.3.3.3. ドメインを分けて物事を考える

3.3.3.3.1. コンテキストマップ

3.3.4. 戦術的設計

3.3.4.1. 解決領域

3.3.4.2. テクニカルなパターン

3.3.4.2.1. 戦略的設計の問題領域に対して、培ってきたアーキテクチャを活用し、解決へと導いていく

3.3.4.3. ソフトウェア開発全ての集大成

3.3.4.3.1. 技術者の過去60年以上の物語

3.3.4.3.2. 様々アーキテクチャを生かして解決へ導いていく