• 目的と手段の混同
  • DDDをやるためにやる
  • 何を解決するために何を取り入れるのか

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

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

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

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

PHP/Laravelからの視点
https://zenn.dev/mpyw/articles/ce7d09eb6d8117

• 自己組織化されたチーム
• アジャイルな環境をつくるためにいくつかの一般的なルールを適用する

https://www.slideshare.net/ran_tan/ss-39514837

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

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

日本は？

• 知識のある人はスタートアップより大企業に行きがち
• 人材の流動性が少ないので、1つの文化・やり方に固執しがち
• 閉鎖的なためそれぞれの企業が独自のやり方で進化をしやすい

• シリコンバレーは手法の均一化
  • 手法の横展開が可能
  • 人材に依存しない（交換可能性をあげる）
  • 機能としての人材→専門性の重視
  • 形式知重視
• 日本
  • 一般化された手法でなく、トップが自由にやり方を決める
    • 人材に依存。(マネージャーガチャ)
  • 人材を均一化することで対応しようとしてきた。平等・同質化。
    • 専門性の軽視
  • 暗黙知重視

シリコンバレーは実はRailsかも

• Start-ups at Silicon Valley are obsessed with Ruby on rails. Why?
  • https://medium.com/@sjami002/to-ruby-or-not-to-be-why-startups-choose-ruby-on-rails-a000ac5708ab
• https://www.jobfluent.com/blog/web-development-frameworks-silicon-valley-vs-europe
• DDD的文脈とシリコンバレーは違うかもしれない

有名企業の言語

• https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

最初はRailsでスケールしたら言語を変える？

• https://www.quora.com/Which-programming-languages-does-Airbnb-use#:~:text=The main programming language that Airbnb uses is Ruby.

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

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

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

変化のしやすさ

• 小さいチーム（２枚のピザ理論）
• 透明性
• 計測の重要性
• それに合わせた変化
  →アジャイルな状態

スクラムガイド
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

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

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

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

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

DDDの文脈

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

アーキテクチャ

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

ドメイン層の分離

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

インフラ層逆転の法則

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

Clean Architectureの図

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

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

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

時系列

• UseCase Driven Approach 1992年
  • https://en.wikipedia.org/wiki/Use_case#cite_note-:3-4
• スクラム開発1993年
• XP 1999年
  • Test driven development
• アジャイルソフトウェア開発宣言 2001年
• PoEAA 2002年
• Domain-driven design 2003年
• Ruby on Rails release 2004年
  • https://en.wikipedia.org/wiki/Ruby_on_Rails#cite_note-initial10announce-1
• Hexiagonal Architecture 2005年
  • https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)#cite_note-2
• Microservices 2005年
  • https://en.wikipedia.org/wiki/Microservices#cite_note-14
• Event Sourcing 2005年
• Ruby on Rails のピーク 2006年
  • https://trends.google.com/trends/explore?date=all&geo=US&q=ruby on rails
  • https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F06ff5
• AWS EC2 Release 2006年
  • https://en.wikipedia.org/wiki/Cloud_computing#cite_note-Amazon.com-14
• Onion Architecture 2008年
  • https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)#cite_ref-5
• Clean Architecture 2017年

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

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に全てのデータを圧縮して入れないといけなかった。
• 当時の技術状況と今は全然違う。
  • 今の方が技術的に恵まれてる分コアドメインに集中しやすい

2002年 PoEAA

DomainModelはこの潮流
https://martinfowler.com/eaaCatalog/

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

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

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

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

• 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

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

ドメインモデル貧血症って概念はDDDよりずっと前からある概念なのか
https://bliki-ja.github.io/AnemicDomainModel/

DDDは前提知識が共有されてた前提で書かれていて、しかもその前提は2003年のもの。
だから現代人にとって難解に見える側面もありそう。

2008年からのRails没落の要因分析

• Twitterの失敗
  • https://www.sitepoint.com/did-rails-sink-twitter/
  • https://www.publickey1.jp/blog/11/twitterruby_on_railsjavavm.html
  • https://jp.techcrunch.com/2008/05/02/20080501twitter-said-to-be-abandoning-ruby-on-rails/
  • スケーラビリティの問題

静的型付けへの回帰(2009-2010年)

• https://www.publickey1.jp/blog/10/gophptiobe.html

関数型言語のブーム

• 2005年でクロック性能向上の頭打ち
  • 並列処理の必要性がでてくる
  • 今まではCPUの性能向上を待てばよかったが、プログラマーの努力が必要になった

https://gihyo.jp/book/pickup/2011/0013

今は関数型とオブジェクト指向の良いとこどり？

モチベーション

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

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

今の日本の状況について

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

個人的な話

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

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

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

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

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

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

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

エヴァンス本

序章

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

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

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

推薦文

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

DDD難民（2007）

https://hanahi.hatenablog.com/entry/20070712/p2

（これ日本だけの概念か？）

ちなみに、はてブによれば「DDD難民」はかくたにさん命名みたいです。

https://aoki1210.hatenablog.jp/entry/20071006/p1

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

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

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/

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/

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

LinkedinのDDD教材

これの目次が興味深い（少なくとも日本のDDD記事でよく見るRepositoryだのUseCaseだのはなさそう）
Agileと相性が良いとも言われてるのが考察の裏付けになりそう。

https://www.linkedin.com/learning/software-architecture-domain-driven-design

LinkedinのMicroservices教材

https://www.linkedin.com/learning/mastering-microservices-with-java

Linkedinのソフトウェアアーキテクチャ教材

https://www.linkedin.com/learning/software-architecture-patterns-for-developers

Domain-Driven Design Europe

やっぱり戦略的DDDに関する発表がほとんど。

YouTubeのvideoIDが不正ですhttps://www.youtube.com/channel/UC3PGn-hQdbtRiqxZK9XBGqQ/videos

Layeredの立ち位置

Layered = MonolithとしてMicroservicesとよく比較されてる?

https://zachgoll.github.io/blog/2019/architecture-types/

MicroservicesとLayeredの関係性について

https://softwareengineering.stackexchange.com/questions/361272/does-layered-architecture-still-to-be-implemented-inside-all-other-architecture

In a microservices architecture, we are particularly interested in the entity and aggregate patterns.
As a general principle, a microservice should be no smaller than an aggregate, and no larger than a bounded context.

https://docs.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd#:~:text=Tactical DDD is when you,the entity and aggregate patterns.

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/

割と丸々DDD勧めてる。
https://microservices.io/book

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

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

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

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

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

わかる

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

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

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

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