왜 DDD 초보자는 굉장히 나오자마자 마음이 굳어져 버리는지

ここである程度イメージをもたせてから、興味があったら原点に当たるというのが良いでしょう。

DDD는 대상 영역이 넓지만, 그것이 이해되지 않고 각각 국소적인 설명이 되어 있는 경우가 많다

DDDの領域は大きく分けて3つに分けられます。

• 開発思想：
  • システムの複雑性に取り組むために、業務の専門家と技術の専門家で言語・モデルの認識を合わせ、継続的に進化させていこう、という考え方
• 戦略的設計：
  • ドメインモデリングの前提を揃えるための、モデリング対象を定義する原則と手法(コアドメイン/サブドメイン、境界付けられたコンテキスト、コンテキストマップ等)
• 戦術的設計
  • モデルを具体的に表現するためのパターン(エンティティ、レポジトリ、レイヤードアーキテクチャ等)

この全体像が整理されないまま、メリットやHowの話になってしまうと、全体像が見えないので何の話をしているのか混乱してしまうのです。

強引に例を挙げるならスクラムの見積もり手法とGoFデザインパターンのいくつかを並べて同時に「開発の効率化とは」と論じるようなものです。それぞれに目的があり、関係性があり、それが繋がって本当にやりたいことができるわけです。

아키텍처 이야기의 가중치가 가볍다.

戦術設計の話で、レイヤー化アーキテクチャについては 「ドメイン層を設けてドメインロジックはそこに閉じ込めましょう」ぐらいで終わっていきなりエンティティやレポジトリパターンの話になってしまう。

これも罠だと思っています。なぜなら、

DDD戦術的設計の最大のメリット、同時に一番頭をひねるところはとにかくアーキテクチャにある

と言っても過言ではないと思うからです。

まず、DDDの推奨するアーキテクチャを採用することによっていかにメリットがあるか。ここについてきちんと時間を割き、その後のモチベーションを高めることがまずは重要だと思っています。エンティティ、レポジトリというパターンは、あくまでレイヤーを綺麗に分ける上でのHowでしかないのです。ここのウェイトの認識を間違えないようにすることが重要です。

しかし！ここからはより具体的な問題が出てきます。。

아키텍처의 모범이 하나로 통합되지 않음

実は、原典でお手本とされているレイヤー化アーキテクチャと、IDDDでお手本とされているアーキテクチャが違うのです。

これは、IDDDでは原典から10年のときを経て洗練されたアーキテクチャになっているということなのですが、これはつまりエンティティなどのデザインパターンは原典でかなり完成されていたのに対して、レイヤー化アーキテクチャに関しては実はある意味未成熟なものであったということ。

そしてそれによりネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。また日本の著名なDDD推進されている方のスライドを見ると、ヘキサゴナルとは思想の異なるアーキテクチャを提案しています。

これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。

앞으로의 이야기

以上、ひとまず導入して思うところをつらつらと書かせていただきました。

ひとまず上記のような分かりづらさがあるよね、というのを整理した上で、私なりに分かりやすいと思う説明の記事を書いていこうと思います。ご興味ありましたら、どうぞおつきあいくださいませ。

후속 기사