【読書】ドメイン駆動設計入門を読み始めた# １章
やってみた系を書くといったですが、
一旦読書記録でジャブを打ちます。
(やってみたはAWSのDBサービスまとめとTerraformでDynamoDBを作るところまでやってみます)
フロント周り(Vueの設計)なのですが、DDDに関する話し合いが発生することがあり、
話についていて行けないことがあるため「ドメイン駆動設計入門」で学び始めました。
とりあえず１章を読んだ忘備録になります。
なぜドメイン駆動設計が必要になるのか
初期段階では、エンハンスで改善する想定で、Railsとかを使って早期にサービスを開発するケースが多くなると思います。
開発者がずっと担当することはないと思うので、代々継いできた開発者が、既存のサービスに継ぎ接ぎで機能を追加していきます。
継ぎ接ぎで開発されて行けばいくほど、システム自体が複雑な構成になってきます。
エンハンスどころか、システム自体のリプレイスが必要になるケースも出てくるのではないでしょうか。
ドメイン(システムの対象概念)に向き合うことで分析、設計、開発までが相互作用的に影響を重ねて、
長期的に動作するシステムを開発することを目的としてのがドメイン駆動設計になります。
ドメインって何？
ドメイン駆動設計は、ドメインの知識に焦点を当てた設計手法になります。
そもそもドメインって？
ソフトウェア開発においてはドメインは、プログラムを適用する対象となる領域になります。
ドメイン駆動設計で、重要なことはドメインが何かではなく、ドメインに含まれる物が何かを考えることになります。
例えば、会計システムの場合に登場する概念としては、
金銭
帳票
等が出現すると思います。
一方で、物流システムの場合に登場する概念は、
貨物
倉庫
輸送手段
といった概念が出現すると思います。
ドメインは、システムが対象とするものや領域によって大きく変わっていきます。
知識に焦点を当てる
ドメイン駆動設計は、知識に焦点を当てると先ほど書きました。
知識に焦点を当てるってどういうことでしょうか。
まず、ソフトウェアの目的は利用者のドメインにおける何らかの問題を解決することです。
利用者が利用するにあたって、
- 現状何に困っている
- 何を解決したいのか
を理解する、つまりドメインが何なのか、何をするのかを整理した上で、
システム化していくことになります。
(技術思考になりすぎてしまうと、この工程が疎かになってしまうとのこと。)
まとめると、ドメインをしっかりと分析した上でシステム化して、
出来上がったときに使い物にならないということを防ぐ設計をしましょうというようなことだと思います。
染みる。
ドメインモデル
モデルは、現実の事象あるいは概念を抽象化した概念です。
ただし、概念の全てを再現するのではなく、必要に応じて取り捨て選択を行います。
(物流システムにおいて、トラックという概念が出現する場合は、荷運びできることだけを考えれば良い)
ドメインの概念を抽象化された(モデリング)後に得られたモデルをドメインモデルといいます。
このドメインモデルを作るためには、開発者だけできないので、利用者と開発者が協力してドメインモデルを作り上げる必要があります。
ドメインオブジェクト
ドメインモデルは、概念を抽象化した知識なので、直接的に利用者の問題を解決することはできません。
ドメインモデルを表現できる、動作するモジュールとして動作するドメインオブジェクト
として表現されることで問題解決に繋がる動作をすることができます。
ドメインに変化(仕様とか概念自体)が起きた時に、真っ先にドメインモデルが変更要求を実現します。
ドメインモデルに変化が起これば実装表現である、ドメインオブジェクトにも変化がおきます。
