DDDとは。。

はじめに

チーム開発でロジックの部分を触る機会があり、クリーンアーキテクチャについての概念的な部分を調べました。クリーンアーキテクチャはRobert C. Martin(Uncle Bob)が2012年に提唱した、DBやフレークワークからの独立性を確保するためのアーキテクチャであり、以下の図が大変有名です。
しかし、この図を見ても僕は全く理解することができなかったので自分なりにわかりやすい記事やサイトを抜粋し、自分の中で落とし込んでみることにしました、。
そもそもクリーンアーキテクチャを理解するにはDomain Driven Design(ドメイン駆動設計)の理解が前提条件としてあります。僕はこのDDDさえも理解していなかったのでそこから調べることにしました、笑

Domain Driven Design(ドメイン駆動設計)

1.開発を進める上で実際の業務をきちんと理解せずに作るとリリースしても全然使われずに不評なものができる。

2.メンテナンス性が悪く整理されていないプログラムを書いたら、後から修正するのが大変になる。

DDDはこのような問題を解決するために生まれた開発手法だそうです。

ドメイン

まず最初に理解する必要があるのがドメインです。
まずドメインとは『　専門領域　』のことです。専門領域と言われても意味が分からないので具体的な例えで説明していきます。

飲食店系列会社に依頼されて、セルフオーダーアプリを作ることになりました。
何から手をつければいいのか？
セルフオーダーのクラスを作るところからなのか？
キッチンのDBモデルを作るところからでしょうか？
そうではありません。
最初にやらなければいけないのは、実際にどのような仕組みでオーダーを取っているかを知ることです。

業務に対する十分な知識がないまま、システムを構築することは不可能です。

ではどのように知ればいいでしょうか。
一体、誰が飲食店のオーダーシステムについて一番詳しいのか？
それはもちろん、実際に飲食店で働かれている方です。
専門領域の話は専門家に伺うのが一番確実だということです。

要するにDDDとは、実際にあるドメイン(専門領域)をどの様に実装に落とし込み、開発に変換して行くかを考えた手法の一つです。

まとめ

頭に思い浮かんだ実装が正しく思えても、実際にドメイン分析してみると、それが全く的を得ていないことがわかったりします。
その差異をできるだけ排除して、可能な限りドメイン(専門領域)に沿った仕様にモデリングをすることが大事なんだということがざっくりとわかりました。

※DDDのモデリングというのは何か問題を解決するために現実世界の一部を抽象化すること