ayumu_aoの日記

SIerから事業会社に転職したエンジニアがなにかを垂れ流してます

ドメイン駆動設計についての学習ログ

自分なりの解釈内容をまとめてみる。

※長くならないようにできるだけ内容をまとめてるので不足が多々あることは承知

内容が正しいかは追って検証。

一言でいうと

ドメイン=業務・事業・利用者の関心事や興味、活動」を知る人が分析し設計・実装を行う

補足?: ドメインをただ知るのみでなく分析するためには、そのドメインの目的・背景までフォーカスを広げることでより理解が深まり、利用者に沿った設計を行うことができる。

噛み砕いてみる

現実の業務・事業をベースに考え、それらの核(本質)となる部分を抽象モデルとして表現する。

また、業務・事業の動作(やりたいこと・知りたいこと)をクラス名とメソッド名で表現する。

業務を適切な粒度でモデリングしそれを共通認識とした設計を行う。

適切な粒度って?

チーム・関係者が誤解を招かない粒度

具体的には?

モデルは一度書いたら終わりではない。ドメインへの知識・理解が深まるたびに修正・加筆を行う

※個人的には加筆は個々人で行うのではなくチームとして行い共通理解とするのがよいと考える

作成したモデルから実装をおこなう

必要な前提技術・知識・環境

まとめ(自分なりの考察)

一言でいうとに『「ドメイン=業務・事業・利用者の関心事や興味、活動」を知る人が分析し設計・実装を行う』と記載したが実際にはそれを一人でおこなう必要はないと考える。

一人ひとりがフルスタック(万能選手)を目指す必要はなくチームとしてフルスタック(万能チーム)であればよいのでチームに所属するメンバーのスキル・知識の総数でカバーする形をめざすのがよい。

では、ドメイン駆動開発に向いているチーム構成はどんなものかを考えてみる。

必要なのはドメインから必要なシステムを設計・構築できることなので業務サイドの人間は必須。

エンジニア、デザインナー、マーケターがそれぞれの役割(専門範囲)からアプローチできる環境ということで

分類 種別 人数 備考
事業サイド 1名〜
開発サイド エンジニア 1〜2名 必要に応じて排除
デザイナー 1〜2名 必要に応じて排除
マーケター 1〜2名 必要に応じて排除
ディレクター 1名 必要に応じて排除

最小構成だとこのくらいがよいのではないかなぁ。。

エンジニアだけの小チームを複数作って作業範囲分解していくということも否定はしないが、ドメインから遠のく気がするので

上記の構成を複数作ってドメインに近い環境を維持するのが良い(気がする)