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

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

はじめに最近、クリーンアーキテクチャ、DDDの本を読んだので、それについて考えたことなどの共有になりますソフトウェア設計とタイトルにありますが、クリーンアーキテクチャはソフトウェアアーキテクチャの話なので、ソフトウェア設計の⼀部分の話になりますね... ※ DDDは読み途中(2020/03/22 現在)

話すことクリーンアーキテクチャについて DDD(ドメイン駆動設計)について技術⼒とコストまとめ

クリーンアーキテクチャについて(1/3) 引⽤元: The Clean Code Blog by Robert C. Martin
(Uncle Bob)

クリーンアーキテクチャについて(2/3) ソフトウェアアーキテクチャ設計の⼿法の⼀つで、コンポーネントに次の4つの依存関係のルールを引くエンティティ：ビジネスルールをカプセル化したものユースケース：エンティティへのデータの⼊出⼒・ビジネスルールの使⽤を制御インターフェースアダプター：データのフォーマット変換(エンティティ→Web向け、など) フレームワークとドライバー：フレームワークやツール(DB, webフレームワーク, など) 円の外側は仕組みで内側は⽅針。依存関係は内側(上位レベルの⽅針)だけに向かっている依存関係の境界線を引いて、依存性を内側に向けてあげることが⼤切なので、4つ以外認めないわけ
ではない

クリーンアーキテクチャについて(3/3) 例引⽤元: Robert C.Martin ( 著), Clean Architecture 達⼈に学ぶソフトウェアの構造と設計,
出版社: KADOKAWA (2018/7/27)

クリーンアーキテクチャから考えられることなぜ依存関係のルールを引くのか → 依存関係の境界線を引くことで、ソフトウェアへの理解を容易にし、変更時の影響を分かりやすくする(クリーンなコードにする) ソフトウェア開発は基本的にチームで⾏う。なのでクリーンなコードであることが⼤切クリーンではないコード、保守性が低いコードは開発スピードが遅く、コストが⾼くなる

DDD(ドメイン駆動設計)について(1/4) ドメインとはユーザーがソフトウェアを適⽤する対象領域(ユーザーの何らか活動・関⼼に関係する部分) DDD(ドメイン駆動設計)とはドメインをモデリングし、モデルを実装と結び付ける。ソフトウェアの中⼼に来るのがドメインモデルとなる設計

DDD(ドメイン駆動設計)について(2/4) DDDの特徴(1/2) ユビキタス⾔語ドメインエキスパート、開発者はお互いに理解できる⾔語でコミュニケーションをとる(それぞれの専⾨⽤語を使って議論しない) ドメインエキスパート：プロジェクトメンバ、ドメインの担当者。ユーザーと違い、その対象に関する深い知識を持っているドメインモデルはユビキタス⾔語に紐づく(ユビキタス⾔語の変更はモデルの変更) 設計に関する本質的な詳細はコード

DDD(ドメイン駆動設計)について(3/4) DDDの特徴(2/2) ソフトウェアの中⼼にいるのはドメイン(例：レイヤードアーキテクチャ) ユーザーインターフェース層ユーザーに情報を表⽰するアプリケーション層ドメインの使⽤を制御するドメイン層ビジネスの概念、状況に関する情報、ビジネスルールを表すインフラストラクチャ層
技術的機能を提供する(アプリのためのメッセージ送信など)

DDD(ドメイン駆動設計)について(4/4) 引⽤元: エリック・エヴァンス ( 著), エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践), 出版社:
翔泳社 (2011/4/9)

DDD(ドメイン駆動設計)から考えられることなぜドメインモデルを⽤意するのか → ユーザーの関⼼ごとと実装を結び付けるため。また、モデルにすることでドメインエキスパートと開発者がお互いに理解しあえるためアプリの仕様に関しての⾷い違い、認識の差異を減らすことが⼤切 → バグの要因を減らすモデルをもとに実装するので、理解しやすいコードとなるモデルの要素=ユビキタス⾔語、アプリの概念がそのままコードとして存在する

技術⼒とコストどんなエンジニア、チームでもクリーンアーキテクチャ/DDDでソフトウェア開発ができるかできない。各メンバーにある程度の設計⼒・技術⼒、選択した設計⼿法への理解が必要となるアプリの仕様との結び付き、依存関係について深く考えられた設計 → ある程度の設計⼒・技術⼒が必要その逆で進めた場合 → ⾼い設計⼒・技術⼒は不要、保守・開発コストが⾼くなるクリーンアーキテクチャ、DDDだけが開発の選択肢だけではないので、チームで実現できる設計⼿法を探
すと良い

まとめアプリの仕様を決める際は認識の差異をなるべく減らせると良いソフトウェア設計では依存関係の境界線(依存性のルール、関⼼の分離）を引いてあげるとクリーンなコードになる設計通りの実装をするにはチームに技術⼒が必要になる

参考 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)

時間あったら DDDの参考になるもの⾒せて説明

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

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

yito

Other Decks in Programming

Featured

Transcript