Zenn
Open72

DDDになぜ失敗するのか

dorarepdorarep

DDDの一部分のみを切り取っている（特に戦術的DDD）

  • 本を読んでない・理解できない
  • ネットの記事で一部分のみわかった気になってる
  • そもそもDDDをできるような前提条件がない、エンジニア以外の協力が得られない（チーム構成など）
dorarepdorarep
  • 目的と手段の混同
    • DDDをやるためにやる
    • 何を解決するために何を取り入れるのか
dorarepdorarep

エンジニアとその他職種の距離

  • 戦略的DDDを適用できない
  • スクラム・アジャイルを適用できない
    →戦術的DDDにのみ注力する。ドメインモデル がない、単にエンジニアが要件からDB設計しただけ。
dorarepdorarep

技術的背景の違い

インフラ層に依存関係逆転の法則をあてるのはJava系では嬉しい。
けどRailsだとFactoryBotで簡単にModelの生成できるので、むしろDIしないほうがテストが楽。
同じように言語などの技術的背景によって相性はあるはず。

dorarepdorarep

ざっくり言えばRailsは依存関係ぐちゃぐちゃでもテストで担保できるよねって感じ。

dorarepdorarep

Mockは実装の詳細をテストが知ってる書き方になってしまうのであまり良くない。（デトロイト学派）

dorarepdorarep

シリコンバレーと日本の文化的違い

ソフトウエア開発者とビジネスの専門家、デザイナーが三位一体隣、定式化された手法によって構想、試作、ユーザによる評価、改良を繰り返して、新たなサービスやビジネスモデルを作り出す

シリコンバレーは決まりごとだらけ

シリコンバレーのマインドセットは「Go　Crazy」でなく「規律を守ろう」

https://www.slideshare.net/atsnakada/ss-80520040

dorarepdorarep

スタンフォード大学とシリコンバレーの密な関係

  • スタンフォードが研究→シリコンバレーの各ベンチャーに共有というスキームがある
  • ソフトウェア開発における座学的知識を共有している人が日本よりは多そう
dorarepdorarep

日本は？

  • 知識のある人はスタートアップより大企業に行きがち
  • 人材の流動性が少ないので、1つの文化・やり方に固執しがち
  • 閉鎖的なためそれぞれの企業が独自のやり方で進化をしやすい
dorarepdorarep
  • シリコンバレーは手法の均一化
    • 手法の横展開が可能
    • 人材に依存しない（交換可能性をあげる）
    • 機能としての人材→専門性の重視
    • 形式知重視
  • 日本
    • 一般化された手法でなく、トップが自由にやり方を決める
      • 人材に依存。(マネージャーガチャ)
    • 人材を均一化することで対応しようとしてきた。平等・同質化。
      • 専門性の軽視
    • 暗黙知重視
dorarepdorarep

シリコンバレーvs日本というよりアジャイルの世界的普及vs日本の普及してなさか。

dorarepdorarep

Agileを採用することで、Agileを採用している企業と文脈を共有することができる。

dorarepdorarep

This might seem a bit controversial, as so many of the organizations famous for their use of microservices are considered startups, but in reality many of these companies including Netflix, Airbnb, and the like moved toward microservice architecture only later in their evolution.
monolith-to-microservices

dorarepdorarep

歴史的・技術的背景

予測が大事な時代

開発に大勢の人、コストがかかる時代
→変更が困難。予測が大事
ex) インフラの調達にハードを購入して繋いでセットアップして... vs クラウド

正確な予測。予定通りに進める力が重要。
→トップダウンで計画。指示通りに動く部下。

時代の変化

  • 予測しきれない
  • 使えないものができる
  • ユーザの反応に合わせて変化させる
  • 買い切り→サブスク
    →正確な予測でなく、変更可能性が大事
dorarepdorarep

大きいプロダクトを小さいチームにするために？

  • マイクロサービス
    →他チームとの調整なく、独立して動ける範囲を増やす

フィードバックループを素早く回すために

  • DevOps(自動テスト, CI/CD)
  • 意見のでやすさ
    • 心理的安全性
  • マイクロマネジメント→自律・自己組織化
    • MBO→OKR
      • どうやるかでなく、何を求めてるかを共有する
      • 抽象度をあげることで、変化に対応できる
      • （どうやるかだと長期的な予測が必要になる）
        →組織構造が目標を共有する必要がある
        →職種による縦割りから、ユニット型へ
dorarepdorarep

DDDの文脈

  • チーム全員でドメインモデルをつくる手法
  • ドメインモデル をコードに落とし込む手法
dorarepdorarep

アーキテクチャ

  • 変えたいけど作り直せない闇
    • もうメンテされてないFWだけど変えられない。
    • DBを変えたいけど変えられない。
  • 変わりやすいところの交換可能性をあげる。
    • 依存関係
    • 責務を明確にする
    • インターフェースを定義、DI
  • テスタビリティ
    • 責務を明確にする
    • 細かい単位でテストする

ドメイン層の分離

  • ドメインは変わらない、サービスにとって一番重要なところ。
  • ドメイン知識がばらけると複雑化。
  • ORM＝テーブル設計などインフラ層に設計が依存する。
    • ドメインモデルをコードで表現することが困難。
    • 検索用・参照用のデータがドメインモデル内に混在（CQRS）

インフラ層逆転の法則

  • （言語/Frameworkによっては）インフラ層が含まれるとユニットテスト困難
  • インフラが変わった時に差し替え可能にする（変化のしやすさ）

Clean Architectureの図

  • 入り口の差し替え可能性
    • PC/iOSアプリ/Androidアプリで細かい制御をしたいケースなど
dorarepdorarep

責務をどこで分けるか、どこでアーキテクチャを切るか

  • スケーラビリティ
    • インフラ的制約
    • CQRS
dorarepdorarep

時系列

dorarepdorarep

MVC

The use of the MVC pattern in web applications exploded in popularity after the introduction of NeXT's WebObjects in 1996, which was originally written in Objective-C (that borrowed heavily from Smalltalk) and helped enforce MVC principles. Later, the MVC pattern became popular with Java developers when WebObjects was ported to Java. Later frameworks for Java, such as Spring (released in October 2002), continued the strong bond between Java and MVC. The introduction of the frameworks Django (July 2005, for Python) and Rails (December 2005, for Ruby), both of which had a strong emphasis on rapid deployment, increased MVC's popularity outside the traditional enterprise environment in which it has long been popular. MVC web frameworks now hold large market-shares relative to non-MVC web toolkits.

https://en.wikipedia.org/wiki/Model–view–controller

dorarepdorarep

DDDが生まれた背景

If you are interested in some historical context on when DDD was created, you should check Tackling Complexity in the Heart of Software
by the DDD creator - Eric Evans
https://threedots.tech/post/ddd-lite-in-go-introduction/

https://www.youtube.com/watch?t=1109&v=dnUFEg68ESM&feature=youtu.be&ab_channel=Domain-DrivenDesignEurope

  • 1990年代前半にSmallTalk EngineerとしてNew YorkのWall Streetの銀行システムでキャリアスタート。
  • 書いたのは2003年。当時は技術状況的に良くなかった。
  • 2003年はJava5しか使われてなかった。(Java8とは全然違う言語)
  • SpringFramework
  • 当時はDBに全てのデータを圧縮して入れないといけなかった。
  • 当時の技術状況と今は全然違う。
    • 今の方が技術的に恵まれてる分コアドメインに集中しやすい
dorarepdorarep

自己組織化
＝人への依存からシステムへの依存へ
＝さらにシステムにシステム自体を改善する機能を含める

dorarepdorarep

ただし当初のWebサービスは、現在のSOAと同様の構想がすでに提唱されてはいたものの、実装技術としてはWebを介したソフトウェアの連携自体に主眼が置かれていた。また、連携する個々のソフトウェア（サービス）をシステム全体の中でどのように位置づけるのか（サービスの粒度の目安を何に置くのか）、多数のサービスを連携させる複雑なトランザクション処理などをどのように設計、実装するのかといった事柄が、課題として残されていた。その後、Webサービスの概念や技術の拡張に伴い、2004年頃から、「Webサービス」に代わって「SOA」がキーワードとして注目されるようになった。

https://ja.wikipedia.org/wiki/サービス指向アーキテクチャ

dorarepdorarep

三層アーキテクチャが有用でなくなったのは

  • poly skilled teams
  • ship software quickly

つまりAgileなチームと相性悪いから。

So that explains why this architecture is so common. It’s not bad; it’s just optimized around one set of forces—how we traditionally grouped people, around familiarity. But the forces have changed. Our aspirations around our software have changed. We now group people in poly-skilled teams, to reduce hand-offs and silos. We want to ship software much more quickly than ever before. That is driving us to make different choices about how we organize our teams, and therefore in terms of how we break our systems apart.
monolith-to-microservices

dorarepdorarep

特に戦術的な部分がPoEAAの流れをくんでると考えると長くても1年ちょっとの実践投入で記事にしてると思われるので、「理論上最強」な側面が強そう。

dorarepdorarep

プログラミング言語のトレンド

https://www.bfcamara.com/posts/most-popular-programming-langs-1965-2019

  • Rubyのオルタナティブは何だろう。
  • 結局このレベルにマクロな統計だとDDD的文脈との乖離も激しそう
  • とはいえ、これだけ圧倒的だと世界はJavaを中心に回ってるのは間違いない

https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F07sbkfb,%2Fm%2F06ff5,%2Fm%2F060kv

dorarepdorarep

議論として成立させるには「DDDの失敗」を定義した方がよさそう。

dorarepdorarep

モチベーション

  • 「DDDでうまくいった」と言って布教してる人がいるのも真実。
  • なんちゃってクリーンアーキテクチャ記事に対する多くの賛同から、「DDDで失敗した」と捉える人が多いのも見てとれる。

どちらの意見にも敬意を評した上で、この違いは何なのかを考察したい。

今の日本の状況について

・2020年にDDD関連の本が出る
→プチブーム
→色々な人が現場で布教する
→「うまくいかないやん！」
だと思ってる。

dorarepdorarep

個人的な話

  • 「DDDやってます！」→軽量DDDのパターンが多い
    • 自分自身の経験として「完璧にDDDやった」と思えたことがない。
    • どこかしらの要素が不足してる。
      • 軽量DDD
      • ドメインモデル貧血症
      • テストがない（ドメインモデルが変更しづらい）
    • 各要素は密接に重なり合っている
      • エヴァンス本の構成要素の図
    • 完璧にDDDをやった場合にどういう世界が待ってるのか見てみたい。
dorarepdorarep

アジャイルの世界的普及に関する調査

米国では、ソフトウェアに対する投資が「自社開発（内製）」「パッケージソフト」で約3分の2を占めており、IT技術者の7割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。

一方の日本では人材の流動性が低いため、技術情報や経験も流通しにくい状態です。

これらから米国、中国、ブラジルなどはIT関連に優秀な人材が多く集まり、アジャイル開発に特徴的な、「チームメンバーが向上心を持ち、常に改善を考える」に合致しており、普及の一因となっていると分析されています。

https://www.publickey1.jp/blog/12/_ipaga.html

dorarepdorarep

「半分以下のチームがアジャイル開発」が最も多く53％、　「全てのチーム」（9%）と「半分以上のチーム」（34%）を合わせると「アジャイル開発がマジョリティ」だとする回答が43％に昇る。

逆に全く導入してないと回答した企業はたったの4％だったようだ。

https://bene-tech.tokyo/アジャイル開発ー世界の動き/

dorarepdorarep

非ウォーターフォール型開発の普及要因と適用領域拡大に関する調査

各国の認定者数を見ると、1 位の米国の認定者数は 2 位の英国の 6 倍以上で、日本と比較
すると約 160 倍と非常に多いことが分かる。Scrum Alliance の拠点がある米国や英国以外の
調査対象国と比較しても、それぞれの認定者数は日本の 10 倍前後で、国内の認定者数が少な
いことが分かる。

https://www.ipa.go.jp/files/000004635.pdf

dorarepdorarep

気になったもの置き場

https://twitter.com/t_wada/status/1290499444467589123

dorarepdorarep

エヴァンス本

序章

根本的には、DDDを駆動してる原則は次の3つだけです。

  • コアドメインに集中すること
  • 土面の実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探求すること。
  • 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること。

逆にいえばそれ以外は交換可能な手段であると考えられるか。

推薦文

DDDのコンセプトの重要性はみんなが理解しながら、それを実践できるだけの土壌・カルチャーができあがってなかったと言うことなのだと思う。
それは、欧米でも同じ位で、OOPSLA2004でのEcir自身によるワークショップに私も参加したが、当時それほど盛り上がっている雰囲気はなかった。
その後、「DDD難民」などという言葉も囁かれた。
それがクラウドコンピューティングという大きな環境の劇変の中で、現場に入って行って現場の声と一体化したシステムづくりのできないソフトウェア屋さんは存在価値がないと言う時代の訪れと共に、DDDの重要性の再認識どころかその実践の必要性に迫られている。

dorarepdorarep

そもそも日本以外でDDDはどう見られてるのか？

Product Technology Manager, Google

I consider DDD to be the current best practice.

N=1だけど2016年時点でbest practiceと言ってるGoogleのエンジニア

The patterns aren't the point
Sadly, many developers, when first learning about DDD, scoop up the technical patterns and don't tarry long enough to absorb the philosophy or strategy.

ここ日本以外も一緒だったっぽい。

Using the patterns of DDD without adherence to the philosophy of DDD reduces the method to a cookie-cutter, mechanical approach to design that can create costly and unnecessary complexity.

完全に同意

https://techbeacon.com/app-dev-testing/why-you-need-domain-driven-design-even-though-you-think-you-dont

dorarepdorarep

Googleエンジニア2

At this point most software engineers are still struggling to apply the tactical and strategic patterns of domain driven design. This was the state of DDD around 2010.

2010年ごろのDDDの状況

Enter Adrian Cockcroft of Netflix fame who along with Martin Fowler sparked the microservices revolution and a renewed interest in DDD as the theoretical underpinning for microservices.

https://twitter.com/adrianco/status/519230249016786944

Here is the full sequence of steps that help with decomposing a monolith:
...
At this point the benefits and promises of DDD become real and the theory of DDD laid out by Eric Evans becomes a pragmatic living software system.

アジャイルが前提

https://cloud.rohitkelapure.com/2019/10/ddd-is-broken.html

dorarepdorarep
  • 2010年ごろまでは日本に限らずみんなDDDを実践するのに苦労していた。
  • Adrian CockcroftがMicrosirvicesの流れでBounded Contextを参照して再注目。
  • それでもモノリス→イベント駆動マイクロサービスに苦労。
  • そのやり方を体系化したEventStormingが生まれて、DDDが民主化された。
  • EventStormingを教科書的に実践すると多くの人が苦労してるCQRSになる。
  • SWIFTメソッドが生まれる。
dorarepdorarep

Netflix

At first, Netflix used a monolith system
However, the growing business requires the monolith system to be broken down into multiple systems, distributing to multiple data sources (microservices).
Recognizing how Hexagonal Architecture could solve their problems of swapping data source, the Studio Workflow team integrated the Hexagonal Architecture by separating the Business Logic from the dependencies as follow:

やっぱMicroservicesの文脈が強い。

https://labs.septeni-technology.jp/design-2/hexagonal-architecture-and-the-netflix-use-case-part-2/

dorarepdorarep

Netflix

You may stop and say “wait a minute… Netflix doesn’t say anything about Domain Driven Design… Neither does Twitter.. nor LinkedIn… why should I listen to this about DDD”?
Well here’s why:

“People try to copy Netflix, but they can only copy what they see. They copy the results, not the process” - Adrian Cockcroft, former Netflix Chief Cloud Architect

引用したい言葉

https://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/

dorarepdorarep

基本的にDDDを参照してるのは戦略的な部分（しかもBoundedContext）が中心で、全体的に戦術的なところに関する言及があまりない。

dorarepdorarep

個々のチームでの実践の話というよりは、日本全体の構造的な問題としてマクロな視点での結論を出したいです。

dorarepdorarep

世界的なWebBackendアーキテクチャのトレンドは？

Netflix

https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749

dorarepdorarep

DDDに対する批判的な意見で目に入ったもの

  • 銀の弾丸はない
  • 実装に時間がかかる
dorarepdorarep

形式知を重んじるのは進化論的世界観なのかもしれない。父性社会的。

銀の弾丸はないことを重く置くのは母性社会的。

dorarepdorarep

銀の弾丸はないのは当たり前で、基本的にどの『パターン』もPros/Consが語られてる。DDDもこういいう場合はやるなって本にも書いてあるし。

とはいえ、一つの弾丸を銀の弾丸のように使いこなせる人もまた尊敬に値するとは思う。
（本当にあらゆる状況下で再現性が高いのであれば）

dorarepdorarep

https://qiita.com/amashigeseiji/items/3ad45bc08d15ecf7b0a7

わかる

われわれは、自らが生み出すモデルとコードによって、ドメインを駆動するのです。
WEB+DB PRESS Vol.120 (Japanese Edition) (Kindle Locations 3939-3940). Kindle Edition.

ドメインに駆動されるのが良いのかドメインを駆動するのが良いのか状況によるけど、視点としてはわかる

dorarepdorarep

ドメインに駆動されるのが良いのかドメインを駆動するのが良いのか

これシリコンバレーでDDDがあまり注目されてない要因かもしれない。
既存のビジネスのIT化→ドメインに駆動される→DDDが有用
新規のビジネスを作る→ドメインを駆動する

dorarepdorarep

日本のDDDの文脈がモノリスなの、高負荷サービス・グローバル展開しているサービスが少ないってのがありそうとふと思った

takutaku

DDDが流行らないのは、小規模プロジェクトで取り入れてみてメリットが感じられないからだと思います。

（最初）「DDD興味あるからサンプルプロジェクトでやってみよう」
（途中）「クラスやファイルが乱立して超面倒だな。なんでユースケース分けないといけないの？」
（終わり）「簡単なことしたいのにコードばっかり増えるな。DDD使えないな」

大規模プロジェクトでこそDDDのメリットが出てくるのに、個人レベルの小規模開発で使おうとする（またはそういった発表が多い）から、誤解されているのかと

dorarepdorarep

DDDのトリレンマ

完全性

全てのドメインロジックがドメインモデルにある。

純粋性

ドメインモデルがプリミティブ型か他のドメイン・クラスにのみ依存する。