この業界に入って3年目のペーペーがDDD(Domain driven design)について書きたいと思います。
DDDについての要約というよりも、より噛み砕いた説明になっているので、かなり冗長かもしれません。
~参考書籍~
Domain Driven design Quickly
エリック・エヴァンスのドメイン駆動設計
現場で役立つシステム設計の原則
DDD(Domain driven design)とは？
以下wikipediaから抜粋(読まなくていいです)
Eric Evans提唱したソフトウェア設計の手法です。
「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする。
具体的に以下の特徴が挙げられる(読まなくていいです)。
・エンティティ (参照オブジェクト): ドメインモデル内のオブジェクトであり、その属性によってではなく、連続性と識別性によって定義される。
・値オブジェクト: 事物の特性を記述するオブジェクトである。特に識別する情報はなく、通例、読み出し専用のオブジェクトであり、Flyweight パターンを用いて共有できる。
・サービス: 操作がオブジェクトに属さない場合に、問題の自然な解決策として、操作をサービスとして実現することができる。サービスの概念は、GRASPにおいて"純粋人工物"と呼ばれるものである。
・リポジトリ:ドメインオブジェクトを取得するメソッドは、記憶域の実装を簡単に切り替えられるようにするため、専門のリポジトリオブジェクトに処理を委譲するべきである。
ファクトリー : ドメインオブジェクトを生成するメソッドは、実装を簡単に切り替えられるようにするため、専門のファクトリーオブジェクトに処理を委譲するべきである。
わかりにくいですね。
新しい概念を学んでる時に、また新しい概念が出てくるとイライラしますよね。
なのでここではできるだけ、すでに知っている概念に置き換えて説明して見たいと思います。
・そもそも何に役立つ物なの？？
私事なんですが、私は既存のコードをこの三年間で色々見てきました。
小規模から大規模な案件、どのコードを眺める時も思ってたことがあります。
「クラスやDBのモデルがたくさんあるけど、どうやってこう設計したんだろう」
ソースコードを見れば、クラスやモデルがどのような動きをするのか理解はできます。
ただ、そのコードを何も見ないで同じ動きをするものを作れと言われたら、作れない気がしていました。
そんな中、現職場のリーダーにオススメされたのが、DDDでした。
なのでこの記事は「ある程度技術がついてきてソースリーディングも行えるが、設計ってどうやるの？」って人向けです
・ドメイン
何はともあれ一番最初に説明しなければいけないのがこれですね。
まずドメインとは『専門領域』です。
意味がわからないと思うので、具体例で説明しましょう。
あなたは航空会社に依頼されて、航空監視システムを作ることになりました。
何から手をつければいいでしょうか？
飛行機のクラスを作るところからでしょうか？
各飛行場のDBモデルを作るところからでしょうか？
そうではないですね。
最初にやらなければいけないのは、実際にどのように航空を監視しているのか知ることです。
業務に対する十分な知識がないまま、システムを構築することは不可能です。
私たちは飛行機が空を飛んでいること以外何も知らないのです。
ではどのように知ればいいでしょうか。
一体、誰が航空監視システムについて一番詳しいでしょうか？
それはもちろん、実際に航空会社で働かれている方です。
専門領域の話は専門家に伺うのが一番確実ですね。
ドメインまとめ
ドメインとは専門領域のことである。
ドメインについて詳しく知るには、専門家に聞くのが一番である。
・モデリング ~ウォーターフォール設計の功績と問題~
誰もが一度は聞いたことがあるだろうウォーターフォール設計
どの様なものかをざっくばらんに説明しますと
1.業務の専門家が要求を書き起こして、それをアナリストへ渡す
2.アナリストはそれを元に設計書を作り(モデリング)、それがソフトウェア開発者へと流れて行く
3.開発者が設計書を元に開発を始める
と言うものです。
この手法はソフトウェア設計の伝統的な手法で、一定の成果を上げて長く使われてきました。
しかしいくつかの問題を内包しています。
その中の一つに
専門家->あなたへと、ドメイン(専門領域)知識が直接渡ってきていないことです。
あなたは、アナリストがモデルに落とし込んだ設計書から、実際にしてほしいことを読みとらなければいけないわけです。
設計書通り作っているうちは問題ないですが、実際のシステムが設計の段階で完璧に収まっていることなどあり得ません。
必ずどこかしらで
「このような状態の時にはどのように振る舞うのが正しいのか」
などの疑問が生まれてきます。
その際、あなたはアナリストへ仕様を伺いに行き、
アナリストは専門家へ何が正しいのかを確認しに行きます。
まるで伝言ゲームみたいですね。
お互いの関心を共有させるのに最も適しているのは、面と向き合って言葉で概念や疑問をぶつけ合うことです。
文字に起こしたり一方通行的な情報フォールだと、知識というのは純度が下がって行きます。
これがウォーターフォール開発が抱えている問題の一つです。
エリックは上記の問題について
「なら初めから専門家と開発者がミーティングすればよくない？」
と考えました。
これらがDDDの骨幹となっている部分です。
前編まとめ
DDDとはつまり、実際にあるドメインをどの様に実装に落とし込み、開発に変換して行くかを考えた手法の一つです。
既存の開発方法で問題が起きていることを、DDDではいろんな方法を使い解決していこうと試みています。
ほぼさわりだけになってしまいましたが
具体的な内容は中編で。。。