クリーンアーキテクチャとDDDで考えるソフトウェア設計/Think about software design

・10-15分ほどで発表する
・クリーンアーキテクチャとDDDの簡単な説明
・それらから考えたこととか

Transcript

1. クリーンアーキテクチャとDDDで考えるソフトウェア設計
2. はじめに 最近、クリーンアーキテクチャ、DDDの本を読んだので、それについて考えたことなどの共有になります ソフトウェア設計とタイトルにありますが、クリーンアーキテクチャはソフトウェアアーキテクチャの話なので、ソフトウ ェア設計の⼀部分の話になりますね... ※ DDDは読み途中(2020/03/22 現在)
3. 話すこと クリーンアーキテクチャについて DDD(ドメイン駆動設計)について 技術⼒とコスト まとめ
4. クリーンアーキテクチャについて(1/3) 引⽤元: The Clean Code Blog by Robert C. Martin (Uncle Bob)
5. クリーンアーキテクチャについて(2/3) ソフトウェアアーキテクチャ設計の⼿法の⼀つで、コンポーネントに次の4つの依存関係のルールを引く エンティティ：ビジネスルールをカプセル化したもの ユースケース：エンティティへのデータの⼊出⼒・ビジネスルールの使⽤を制御 インターフェースアダプター：データのフォーマット変換(エンティティ→Web向け、など) フレームワークとドライバー：フレームワークやツール(DB, webフレームワーク, など) 円の外側は仕組みで内側は⽅針。依存関係は内側(上位レベルの⽅針)だけに向かっている 依存関係の境界線を引いて、依存性を内側に向けてあげることが⼤切なので、4つ以外認めないわけ ではない
6. クリーンアーキテクチャについて(3/3) 例 引⽤元: Robert C.Martin ( 著), Clean Architecture 達⼈に学ぶソフトウェアの構造と設計, 出版社: KADOKAWA (2018/7/27)
7. クリーンアーキテクチャから考えられること なぜ依存関係のルールを引くのか → 依存関係の境界線を引くことで、ソフトウェアへの理解を容易にし、変更時の影響を分かりやす くする(クリーンなコードにする) ソフトウェア開発は基本的にチームで⾏う。なのでクリーンなコードであることが⼤切 クリーンではないコード、保守性が低いコードは開発スピードが遅く、コストが⾼くなる
8. DDD(ドメイン駆動設計)について(1/4) ドメインとは ユーザーがソフトウェアを適⽤する対象領域(ユーザーの何らか活動・関⼼に関係する部分) DDD(ドメイン駆動設計)とは ドメインをモデリングし、モデルを実装と結び付ける。ソフトウェアの中⼼に来るのがドメインモデルとなる設 計
9. DDD(ドメイン駆動設計)について(2/4) DDDの特徴(1/2) ユビキタス⾔語 ドメインエキスパート、開発者はお互いに理解できる⾔語でコミュニケーションをとる(それぞれの専⾨ ⽤語を使って議論しない) ドメインエキスパート：プロジェクトメンバ、ドメインの担当者。ユーザーと違い、その対象に関する深い 知識を持っている ドメインモデルはユビキタス⾔語に紐づく(ユビキタス⾔語の変更はモデルの変更) 設計に関する本質的な詳細はコード
10. DDD(ドメイン駆動設計)について(3/4) DDDの特徴(2/2) ソフトウェアの中⼼にいるのはドメイン(例：レイヤードアーキテクチャ) ユーザーインターフェース層 ユーザーに情報を表⽰する アプリケーション層 ドメインの使⽤を制御する ドメイン層 ビジネスの概念、状況に関する情報、ビジネスルールを表す インフラストラクチャ層 技術的機能を提供する(アプリのためのメッセージ送信など)
11. DDD(ドメイン駆動設計)について(4/4) 引⽤元: エリック・エヴァンス ( 著), エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践), 出版社: 翔泳社 (2011/4/9)
12. DDD(ドメイン駆動設計)から考えられること なぜドメインモデルを⽤意するのか → ユーザーの関⼼ごとと実装を結び付けるため。また、モデルにすることでドメインエキスパートと開発 者がお互いに理解しあえるため アプリの仕様に関しての⾷い違い、認識の差異を減らすことが⼤切 → バグの要因を減らす モデルをもとに実装するので、理解しやすいコードとなる モデルの要素=ユビキタス⾔語、アプリの概念がそのままコードとして存在する
13. 技術⼒とコスト どんなエンジニア、チームでもクリーンアーキテクチャ/DDDでソフトウェア開発ができるか できない。各メンバーにある程度の設計⼒・技術⼒、選択した設計⼿法への理解が必要となる アプリの仕様との結び付き、依存関係について深く考えられた設計 → ある程度の設計⼒・技術⼒が必要 その逆で進めた場合 → ⾼い設計⼒・技術⼒は不要、保守・開発コストが⾼くなる クリーンアーキテクチャ、DDDだけが開発の選択肢だけではないので、チームで実現できる設計⼿法を探 すと良い
14. まとめ アプリの仕様を決める際は認識の差異をなるべく減らせると良い ソフトウェア設計では依存関係の境界線(依存性のルール、関⼼の分離）を引いてあげるとクリーンなコ ードになる 設計通りの実装をするにはチームに技術⼒が必要になる
15. 参考 The Clean Code Blog by Robert C. Martin (Uncle Bob) Robert C.Martin ( 著), Clean Architecture 達⼈に学ぶソフトウェアの構造と設計, 出版社: KADOKAWA (2018/7/27) 和⽥ 卓⼈(@t_wada), 質とスピード（2020 春版） / Quality and Speed 2020 Spring Edition, 2020/02/13 エリック・エヴァンス ( 著), エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発 の実践), 出版社: 翔泳社 (2011/4/9)
16. 時間あったら DDDの参考になるもの⾒せて説明