事実と解釈とドメイン駆動設計

meijin
·

ドメイン駆動設計という言葉を知って3年、最近はドメインとは何かということを考え詰めています。

少し前まで「ドメインとは事業の競争優位性になりうるものだ」と説明してきましたし、自分はそれで納得できていたのですが、周囲にいまいち伝わらないなと思っていたからです。

そこでここ数日思うのは事実と解釈について。

たとえば外で雨が降っていて、傘を持っていくと判断したとします。

このとき、雨が降っているという事実に対して、傘を持っていかなければ濡れてしまうと解釈したというように分解できます。

さらにいうと、雨が降っているというのも解釈だと言うことができます。

外を見ると少し暗くて水滴が空から落ちていた。その事実に対して雨が降っていると解釈し、さらにその状況に対して、傘を持っていかなければいけないと解釈しています。

このように、現実世界はより事実に近いものと、より解釈に近いものでグラデーションになっているのです。

これをシステム開発に応用します。たとえば、ユーザーがアカウント登録してから30日経つと、マイページに「おめでとう」と表示する仕様があったとします。

このとき、マイページを表示するフロント画面から叩かれるAPIで、ユーザーがアカウント登録してからの日数を取得し、30日以上であれば「おめでとう」と表示することで要件が満たせます。

しかし実際は、APIは「おめでとう表示対象か」を返すものとして開発し、API内部に30日以上かのロジックを閉じ込めるほうが望ましいことが多いです。そのほうが、あとからおめでとう表示ロジックが変わったとき、フロント画面の改修をしなくても仕様を変えられるので、ネイティブアプリを提供していたりしても簡単に対応できます。

ここで、ユーザー登録後の日数という事実と、おめでとうを表示するという解釈が存在し、解釈はAPIより向こう側に持たせたほうが保守性が高いという洞察が得られます。

このように、解釈をより裏側というかデータベースに近いところに持たせて、かつ持たせるレイヤーを統一することで、開発しやすく、意思決定しやすく、保守性も高まる傾向にあるといえます。

このとき解釈を担当するレイヤーをドメイン層と考えると、割と納得がいきます。

@meijin
名人です 趣味とエンタメの話題をメインで書きます