初めに
DDDって言葉自体は定期的に聞きますよね。
ドメインについて知識をつけましょう、みたいなことはよく言われますが
「ドメインってIPアドレスをURLにしたものだよね〜」
くらいの理解しか去年まではありませんでした。
ドメイン知識やDDDとか聞いても、「プロジェクト全体のルーティングの理解かな」って感じで半年くらい前までは恥ずかしながら間違った理解で解釈してました😇
聞いたことはあるけど、詳しくは知らないという方は沢山いると思います。
自分自体ふんわりとした理解しかなかったので、今回勉強を兼ねてまとめさせて頂きます。
そもそもでドメインって?
ここでいうドメインとは専門領域のことであったり、ドメイン知識のことを分かりやすくいうと業務知識のことになります。
請求書系アプリで例えると締め作業や簿記の知識等ですね。
余談ですが、学生時代に取得した簿記やFPの知識もエンジニアになってからも役に立つことはありました。
DDDとは?
DDDとはDomain-Driven Designの略で日本語ではドメイン駆動設計と呼ばれています。
以下wikipediaから抜粋
ドメイン駆動設計（英語: domain-driven design、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計手法である。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。
開発者は通常モデルを純粋で有用な構造として維持するために大量の分離とカプセル化を実装する必要があると批判されているが、ドメイン駆動型設計は保守性などの利点を提供する。一方でMicrosoftは、モデルがドメインの共通理解を策定する上で明確な利点を提供する複雑なドメインにのみ推奨している。
正直、何言ってるかわかりにくいですよね。
端的にいうと、DDDはソフトウェアで解決したい部分(専門領域)を、ソフトウェアの設計にそのまま反映させる、もっと簡単にいうと業務をちゃんと理解した上でソフトウェア開発を行うといった意味合いになります。
DDDの根幹
業務を理解して、アプリ開発することは当然と思うかもしれません。
しかりウォーターフォールを例に出すと
上記を見ればわかるかもしれませんが、エンジニアにドメイン知識(業務知識)が直接渡ってきません。
開発者はアナリストがモデルに落とし込んだ設計書から、実際にして欲しいことを読み取る必要があります。
設計書の内容を完璧に作れれば問題ありませんが、実際の業務で中々そうはなりません。
必ずどこかで、「このような状況ではどのように振る舞うのが正解か?」
等々の疑問は生まれます。
そこでエンジニアがアナリストへ仕様を確認し、アナリストが専門家へ何が正しいのか確認する必要があります。
無駄なコミュニケーションコストがかかりますね😇
初めから「業務の専門家」と「エンジニア」が直接ミーティングすれば良いじゃんという考え方がDDDの根幹です。
ユビキタス言語とは
エンジニアと専門家の間では、同じ概念を保持しても別の名前をもった言葉がいくつもあります。
開発者サイドからすれば「ツイート機能」、専門家・他職種の人からすれば「つぶやき機能」といったものですね。
それを統一するものがユビキタス言語になります。
毎回脳内変換していれば、コストがかかってしまいますし誤認識の要因にもなります。
ユビキタス言語を使えばDDDも円滑に行うことができますね!
まとめ
いかがでしたでしょうか。
エンジニアとして業務を行う際に、業務知識のあるなしで「DB設計」や「システムのフロー」を
適切に考えれるかどうか決めると言っても過言ではなありません。
今回の記事が多くの方に参考になったら幸いです。
テスト駆動開発(TDD)についてもまとめてるのでよかったら見てみてください！
参考記事