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

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マネジメントで大事なのは、計画や実行だけでなく、状況を見極め（計測）、対応する行動をおこす（調整）ことですよ。なので、マネジメントの土台にもアーキテクトの「ドメイン（問題領域）を見極める能力」は極めて重要です。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

ドメインモデルはビジネス上のデータ活用についての仮説を表している、、というのは認識していただきたい。平面的にデータを捉えるのではなく、立体的にデータを捉えるのがモデルですよっと。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

アジャイルにPMが不要だというのは、計画、実行、計測という機能はプロセスに溶け込ませてスクラムマスターが支援する。そして、調整機能はプロダクトオーナーに委譲される。だから、マネジメントが不在なわけではない。でも、POはすごく重要。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスの背景には二重の意味でクラウドがある。1.サービス運用/運営が重要になり、より進化的な設計が必要なったことと、2.共有化されたプラットフォーム層の登場により、サービス個別の独自性が認めやすくなったこと。両面から理解することで技術面と文化面の特徴が分かる。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスは新しい技術パラダイムというより、現状の混乱を肯定的に認め、積極的に解決しようとする「文化論」だと思う。エンプラ業界的には「標準フレームワークも標準プロセスも不要」というのが衝撃的なのではないか。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

「構造における標準化が不要」というのは標準化による効率化よりも、独自性を優先された方が無駄が少ないということで、開発プロセス論におけるWFからアジャイルへ、という議論とよく似ている。アジャイルは「計画の無駄」を語ったが、構造では「ライフサイクルの無駄」を語るべきかな。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

プロセス論におけるWFからアジャイルへ、と、構造論におけるモノリシックからマイクロサービスへ、の比較については、SOAも交えつつ、語りたいな。都合の良いイベントがないものか。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

プロセス論でのWFからアジャイル、構造論でのSOAからマイクロサービス、どちらも中央集権から分権への流れと考えると分かりやすい。それだけ物事が複雑になったということ。構造が遅れたのは「構造だからプロセスより変化が遅い」ということとクラウドの広がりだろうな

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

@kazuho はい、同意です。レガシーはレガシーとしての仕組みやプロセスを残しつつ、新しい部分は新しい仕組みとプロセスでやっていくというギャップは大きな要因ですね。あとは犠牲的アーキテクチャの議論も近いかと

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

@kazuho なるほど。僕の観測範囲だとECサイトのような幅広い業務と要件があるクラウドサービスは積極的にマイクロサービス化していると感じています。フロントはスケーラブルにしても、請求や物流関係は複雑なわりにスケールは不要なので。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

@kazuho はい、ライフサイクルや性能要件が異なる部分でサービスを分けるのは定石かと思います。最初にレスいただいた、Web系企業もエンプラ並みにレガシー問題が出てる、というのは面白い話だったので参考になりました！ありがとうございます。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

機能品質とサービス品質は違う。機能とは「単一のユーザーに対して提供される理論的な振る舞い」であり、サービスとは「ビジネスとして持続的に利用される状況での振る舞い」のこと。後者には性能や可用性、保守性などが含まれる。後者は非機能要件などと呼ばれるけど、名前を変えたほうがいい

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

非機能要件はサービス品質要件と呼んだ方がしっくり来るな。非機能と言われると「機能以外のなんか」みたいになるけど、サービス品質なら「機能が持続的に利用されうる状況を維持する」という積極性を感じる。サービスレベルと表裏。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

政治学から見たマイクロサービスを妄想。SOAという"失敗した立法君主制"から、MSAという封建制への回帰。封建制に必要なのは"法"ではなく"宗教"という規範。MSAにおける宗教とはなにか。あるいは資本主義は宗教の代替になるのか。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

マイクロサービスがバズって「API単位でノード分散するのがマイクロサービス！」とか言い出して、APIごとにバージョン管理や整合性管理したりデプロイ管理したりサーキットブレーカー設定したりして開発中に複雑怪奇になって頓挫する案件が出てくるのに100ペリカ

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

アーキテクチャ設計って、プロジェクトの立ち上げ方みたいなのを含めて考えないといけないのですが、まぁ簡単じゃないよね。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

AzureのService Fabricのような「APIレベルでマネジメントをする」のはマイクロサービスアーキテクチャというよりも、ナノサービスアーキテクチャみたいな呼び名で分けた方がいいと思うんだよね。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

ライブラリのAPIを利用してソフトウェアを作ることと、サービスのAPIを利用してサービスを動かすことの差は面白い。静的構成と動的構成の差なので、そのデザイン手法もプロセスも違うのです。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

ITエンジニアの仕事は「コードを書いてソフトウェアを作る」から「コードを書いてサービスを動かす」に変わってきている。機能とサービスの違いを意識することはすごく大事。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

オブジェクト指向で重要なのは、クラス設計ではなく、インスタンス化されたオブジェクトの設計です。クラス設計は結果であり、目的ではない。ユニットテストはクラスではなくインスタンスがテストできるから面白い。こういう違いをつかめるセンスがあると優秀なエンジニアになれる

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

ITのデザインは「いかに美しく配置するのか」だけではなく「いかに美しく動かし続けるのか」が重要になる。分かちがたいが、別のこと。このセンスがないと良いものは作れない。ITは静的な状態では評価ができないのです。ようやく、最近になってやりやすくなってきた。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

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

杉本啓 @sugimoto_kei

「方法論を熟知していて分野を問わず何でもできる業務システムエンジニア」などではなくて「会計システム屋」とか、「小売業の店舗管理システムのプロ」、「PLMシステムを語らせたら丸一日語る男」などを目指す人が増えたら、ドメイン指向設計なんて自然に達成されると思う今日この頃。

杉本啓 @sugimoto_kei

マリノフスキとかレヴィ=ストロースといった、人類社会のありようについて深い洞察をもたらした人類学者は、だいたい、特定のごくマイナーな民族集団の精緻な研究からスタートしてるんだよね。 業務システム開発でも同じじゃないかしらね。RT @sugimoto_kei

杉本啓 @sugimoto_kei

マイクロサービスってのの元記事、初めて読んだ。サービスの粒度は、DDDで云うところの「境界づけられたコンテキスト」とだいたい同じ程度を想定してるんだね。「マイクロ」と呼ぶと、極端に小さな粒度を想定しているような誤解を与えないかね。martinfowler.com/articles/micro…