マイクロサービスとドメイン駆動設計の設計思想のTwiiter拾い

杉本啓 @sugimoto_kei

「境界づけられたコンテキスト」はモデルに関する概念ですけれど、それに対応する実装上の選択肢のひとつとして、「マイクロサービス・アーキテクチャ」があるって理解でよろしいんじゃないでしょうか。RT @sugimoto_kei

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

@yujiorama むしろ、コンウェイの法則は非常に本質的な指摘で、MSAは、それを推し進めたものだと思ってますよ。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

[再掲]久しぶりにブログを書きました。最近、よく考えているマイクロサービスアーキテクチャについてです。 マイクロサービスアーキテクチャとは何か - arclamp arclamp.hatenablog.com/entry/2015/06/…

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスが「複雑だけど技術的に興味深い」ものになってて残念。それを目的にしちゃダメなんだって。もっと、ゆるふわに取り組まないと。 twitter.com/infoqjapan/sta…

infoQ Japan @InfoQJapan

ニュースをアップしました『マイクロサービス移行の代償 』#InfoQJapan infoq.com/jp/news/2015/0…

2015-06-17 12:59:33

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

「マイクロサービスで設計しました！」って、最初から細かいドメイン分割とバラバラのFWを持ってくるとかダサすぎ。何を持ってドメイン分けたの？それただの機能分割だよね？FW細かく分けておいしいの？そんなにエンジニアいるの？分けたメリットあるの？キューでよくね？誰が監視すんの？

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスを組み立てるのは機能だけではなく、運用面で大きな負担がかかります。監視やリリースの自動化だって大変な作業です。そういう設計するから象牙の塔とか言われちゃうんだよ

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

モデリングは「粗い粒度の動的モデルから始める」が基本。みんな細かい静的モデルから書きがちだけど、矛盾や勘違いが起こりやすくなる。人間の脳は時間軸に沿って個別ケースを考えるようにできていて、分岐による平行時間の拡がりや時間軸を無視した空間的構造をいきなり考えるのは不得意

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

ドメイン駆動設計が向くのは「ソフトウェアの動作が顧客とモデルによって合意できて、コードによる検証が適切に行える領域」なので、時間軸を持つ業務プロセスよりも、IN/OUTが明確な計算が主体な場合に適していると思うよ。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

そもそもオブジェクト指向は時間軸を表現するのは苦手。とはいえ時間軸をベースにする方式では集約がされずに再利用ができなくて効率が悪いという問題があります。だからモデリングによって時間軸における空間配置を検討し、適切なバランスを探すことが重要になります。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

モデリングというのは時間と空間を扱っていて、基本的には「時間軸で展開される物語を空間的な箱の中に押し込める」ので、いろいろと矛盾は出ます。そして「変化」という時間軸最強の悪魔に対して開発プロセスに頼らざるを得ないのはソフトウェアの限界をよく表していますね

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

アーキテクト的に発言すると、構造が柔軟であれば開発プロセスなんかに頼ることはないのですが、どうしても限界があるわけです。ま、昔よりは良くなっててクラウドは革新でした。ただ、特定のユースケースに依存してます。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスは「構造を先に決めでも意味ないから、そのドメインに適した構造を決めたらいいじゃん」という当たり前のことをかっこよく言っているだけです。なので「マイクロサービスという構造がありましてね」というのは自己矛盾ですよ。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスが僕にとって面白いのは、それが技術タームのふりをして、これまでのソフトウェア工学で繰り返されてきた標準化を全否定するから。その点ではプロジェクト管理工学に対するアジャイルとよく似てる。なので、アジャイルのように紆余曲折があるだろうと思ってます。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

僕はアジャイルもマイクロサービスも好きですが、理解していないことで不幸になることだけが悲しい。そして、そこにのっかって商売をしたあげく「分からない人にはうまくいかない」とか偉そうに言う奴が嫌い。アジャイルもマイクロサービスも状況に適応せよと教えているのに！

杉本啓 @sugimoto_kei

マルチパラダイムデザインのひとつの示唆は、たぶん、ソリューションの枠組みがない状況で問題を定義するのは極めて難しいということ。複雑な問題は、特定の枠組みの中で解決することを通じてしか定義できない。いったん定義すれば、別の枠組みに移し替えるのは難しくない。とてもおもしろい。

杉本啓 @sugimoto_kei

コプリンさん、頭良すぎ。RT @sugimoto_kei マルチパラダイムデザインのひとつの示唆は、たぶん、ソリューションの枠組みがない状況で問題を定義するのは極めて難しいということ。...

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

そのプロジェクトがSOAかマイクロサービスか、あるいはウォーターフォールかアジャイルか、というのは最初に決まることじゃない。ある部分は外部与件から「していく」けど、やはり人や技術を寄せていくことで自然に「なっていく」のが理想的だよ。

杉本啓 @sugimoto_kei

そうだよねえ。あれはモデリング手法の本じゃないよねえ。 RT @iteman ドメイン駆動設計が時間軸が苦手ってわからないなぁ。具体的なモデリング手法をほとんど提供していないのになぜそんな話になるんだろう。

杉本啓 @sugimoto_kei

ドメイン駆動設計については、「コアドメインが大事」「モデルはユーザサイドではなく、エンジニア自ら深めていくべきもの」っていう「気持ち」だけ受け止めておけばよいと思う。

杉本啓 @sugimoto_kei

「ドメイン駆動設計は好きだけれど、特定の対象業務分野に縛られるのはイヤ」とか、ふつうにありそうだな。

杉本啓 @sugimoto_kei

ドメイン駆動設計を学ぶより、まずは、ひとつのドメインに没入して、その分野の本を読み、仕事をしてみるなどして、それでもなにか、飽き足りない、このドメインではもっと素晴らしいものが作れるはずだ、と感じ始めたらドメイン駆動設計の本を読むのがいいと思う。