なぜドメイン駆動開発が必要か？エリックエヴァンスのドメイン駆動開発で勉強したこと（１〜３章）
久々の更新。今まで文章を書くのに時間をかけてダルかったけど書きダメを覚えたので再開。
今回は、機械学習やpythonが関係ないです。 ただ優れた設計をしたくなったらドメイン駆動開発にたどり着いたので、有名なエリックエヴァンスに手を取ることに。 モチベーションとしては、その思想自体は前々から知っていたものの、qiitaの知識程度で使ってみたら失敗したことから。
ドメイン駆動開発がどんな意味を持つかが１章から３章に書かれていたので、気になった部分まとめです。
気になった部分をメモして、それをまとめただけなので読みづらいかも
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
この記事の対象読者
機械学習やpythonというよりかはソフトウェアの設計です。
ドメイン駆動開発についてqiitaとかで見たことあるけど、正しい使い方やメリットがわからない人向けには参考になるかと。
ちなみに、ドメイン駆動開発の対処者に関しては、本書にも書かれていますが、 プロジェクトの開発リーダーが特にオススメなんじゃないかなと思いました。 ドメイン駆動開発は要件が複雑なアプリを設計する際に有効だということなので。 ただし、後述しますがコーダーも設計に関する知識も要するので、 ドメイン駆動開発を採用する場合は開発現場で回し読みするのがいいと思いました。
ドメイン駆動開発とは？
簡単に言えば、ビジネスロジック（要件定義だったり課題へのアプローチっていうイメージ）をわかりやすくするための設計。 もっと言えばプロジェクトに変わる非開発者（特にビジネスや課題の有識者、本書ではビジネスエキスパートと表現）でもわかりやすく機能をモデリングしようって話。
特に本書で議論されるレイヤードアーキテクチャは ビジネスエキスパートの要求（要件定義とか）と実装の都合（特に技術的すぎる部分）を切り離して、 後者を隠ぺい化しようっていう目的
っていう認識を前から持っていた。合っているかな？
クリーンアーキテクチャとかDDDに関するデザインパターンは結構議論されているから、技術者はそっから入った方がわかりやすいかも
ググれば以下のような記事が出るので後は先駆者の有志記事に任せます。
まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita
ちなみにアジャイル開発と相性が良さそうです。
ドメイン駆動設計のやり方
本書の一例をざっくり説明すると要件定義をしながらモデルの設計をしている感じです。 具体的にはうまく説明できる自信がないので省略。
本書で１章ではUMLを使ってモデルの設計をしていましたが、気をつける点は
- モデルとコードは紐付ける（対応させる？）
- モデルはドメインエキスパートと話しながら継続的に良くする。モデルは変化するもの。
- モデリングのときはチームが理解できる単語を使う。使う図もUMLである必要は必ずしもない。
- モデルの設計はブレストをしながらが効果的。要件の洗い出しのためか。
- 知識豊富なモデルにする、出来たモデルは蒸留する
- つまりドメイン知識は洗い出して、その後に本質ではない不要部分を切り捨てる
とドメインエキスパートとの会話が重要になるかと。
ドメイン駆動開発のいいところ
- アプリが複雑になった場合にシンプルになる。大規模な状態なったりとか？
- ビジネスロジックが見やすくなる。特にビジネスロジックの部分が非開発者含めたチーム内で共有しやすくなる。
- テストがしやすくなる。ビジネスロジック自体がテスト対象のインターフェイスになるから？
特に２番目が大きな効果を及ぼすかと
ドメイン駆動開発が生きないパターン
以下の条件が絡むと意味がなくなる
- コーダーがモデルに対して責任を感じていない
- アプリケーションに対してモデルを機能させる方法がわからない
- コードを変更するとモデルが変わることを理解していない
- モデリングする人が実装に携われない
ドメイン駆動設計のデメリット
- モデル駆動設計は敷居が高い（学習コストが高い）
- 開発に時間がかかる
ドメイン駆動開発を導入が困難な場合
特にわざわざドメイン駆動を使わなくてもいい場合はこのようなアーキテクチャが有効とか。
この印象から例えばMVCがこれに該当するのかなという印象
ドメイン駆動の使いどころ
本書を読んだ限りだと
- 要件が固まっている
- モデルが複雑になる
場合に有効という印象
逆に要件を分析するためにプロトタイピングしたりビジネスロジックが簡潔にできるのであれば使う必要はないかと。
