fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方」に参加しました

2016/5/25(水) 「DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方」に参加してきました。

connpass
http://ddd-alliance.connpass.com/event/31834/

場所は銀座の株式会社ドワンゴさんです。
参加者は100人くらいでしょうか。毎度の満席です。

これまでDDDAllianceの講演は、(無料のは)ほとんど皆勤で参加してます。
いつも学びが多く、今回も楽しみでした。

以下、スライドに無い口頭説明部分を中心に、メモ。


講演


ドメインオブジェクトの見つけ方・作り方・育て方 from 亨 増田



最初に
  • 今日は、自分たちがどうやってDDDをやってきたか、をできるだけ生でお伝えできればなぁ。
  • ドメインオブジェクトの設計の話は
    • 「オブジェクト指向エクササイズ 9つのルール」とか
    • 「リファクタリング」とか
    • バートランド・メイヤーのモジュール性の話とか
  • これらを私自身、勉強してきたし、現場でここらへんが基礎となって生きてきている。
  • 今日は具体的に「どういうことなの」と繋げていければ。


4冊に共通する価値観 (P.5)
  • 4冊の本に共通する価値観がある。
  • それは、「複雑なものは変化するし、それに立ち向かうには自分たちも変化しなければならない」ということ。
  • 完全に予測することは不可能。価値観、実践のノウハウ集としてドメイン駆動設計を活かしている。
  • オブジェクト指向とアジャイルは、片方だけでは成立しないと考えている。
  • 変更容易性を重視するなら、作るならオブジェクト指向だし、プロセスならアジャイルなのでは。
  • 同じ価値観がデザイン側とプロセス側の側面で2つあるが、同じ活動なんだろうなと思う。


オブジェクト指向の開発スタイル (P.6)
  • Interactive
    • XPとかをケント・ベックは重視している。
    • コミュニケートすることの重要性を基本に据えている。
    • 会話的にやりとりしていくことを重視している。
  • Synergy
    • Iterative、Incremental、Interactiveのシナジー効果が、複雑さに立ち向かうための狙いなのでは。
    • 相乗効果ということ。


設計原則 (P.8)
  • 設計を考えるとき、複雑さに立ち向かう根本は「モジュール性」にある。小さいものを組み合わせて構成する。
  • オブジェクト指向が考えているモジュール性と、機能分割のモジュール性は考え方が根本的に違う。凝集性も同じ。
  • なので、どちらの文脈なのか合わせないと噛み合わない。


モジュール性の基準 (P.9)
  • バートランド・メイヤーが、オブジェクト指向の狙いなどを分厚い本の中で書いてる。
  • 3章か4章でモジュール性を取り上げて重要視している。


モジュール性の評価基準 (P.10)
  • バートランド・メイヤーのモジュール性の評価基準は5つの評価軸がある。

  • 1.分解しやすい
    • まず、分解の話が最初にある。
  • 2.組み合わせやすい
    • 分解したモジュールを組み立て直すときに、他の組み立て方もできるのが良い。
    • オブジェクト指向と機能分解の大きな分かれ目がここ。
  • 3.わかりやすい
    • モジュールを見ただけで、こんなことやろうとしているんだな、とわかる。
    • 呼び出す側とかまで読まないと自分自身を理解できないというのはモジュール性として劣る。
  • 4.連続性
    • 最も重要なモジュール性の尺度。
    • 仕様の変更に対して、モジュール側の変更がばらつくのは悪いモジュール性。
    • ある1つの要求を、プログラムあちこちを直さないと保証できないのは悪いモジュール。
    • ばらつく、という言葉に意味が合って、ある時は1対1に対応しているように感じて、ある仕様に関してはあちこちに影響が及んでしまうような、共通性がないものは、不連続である。
    • ドメイン駆動設計はここをすごく意識している。
    • 同じ振幅でプログラムにも影響するのがよい連続性。
  • 5.保護性
    • 影響が波及しないように作ってあるのがよい保護性。変更が楽で安全なら、良いモジュール。


モジュール性:2つのアプローチ (P.11)
  • 1.機能分割
    • Javaはクラスを作れば、クラス単位でモジュールになる。
    • Javaで「機能クラス」と「データクラス」に分けるという考えはよくある。
  • 2.オブジェクト指向
    • 抽象データ型で作っていくのがメイヤーの考え方。こちらがキーになる。


機能分割:機能クラスとデータクラス (P.12)
  • 機能クラス、データクラス、という考え方は、C言語とかCOBOLとかを踏まえて自然的に出てきた考え方。
  • なので、getter/setterがある、エンティティビーンとセッションビーンに分ける、というスタイルが広がったのは合理的。
  • getter/setterの入れ物を宣言するのが@Entityだよ、とマニュアルに書いてあって、これが正しいという確信犯。
  • この世界でJavaを使っていたら、今日の話は違和感があるはず。


オブジェクト指向:抽象データ型 (P.13)
  • 「外から見た時、どう見えるか」、「内部でどう使うか」が一致していない作り方。


抽象データ型の例 (P.14)
  • String
    • 内部のデータ表現はcharの配列。
    • 外部からは、substringしろ、などの命令に対する結果だけを返す。
    • 内部がどういう処理ロジックで書かれているか関係なく、こうしたいんだ、といえば結果を返してくれる。
  • BigDecimal
    • 内部はBigInteger型のintValと、桁数を表すint scaleで表現される。intValはintの配列。
    • 小数の桁数は21億桁分まで持てる。
    • でも、使うときはだれもそんなこと意識していない。
    • 人間が数字を使いたい時の機能が公開メソッドとして定義されている。
  • LocalDate
    • 外から見た時は「何ヶ月前の日付を返せ」、とか、日付について人間が興味が持っていることをオブジェクトとして提供している。
    • 内部的にどうデータ持ってるかは関係ない。
  • ArrayList
    • 内部的にaddしたときに配列の要素が足りなかったら配列をもう1回作るんだけど、性能が悪くなるから複雑な処理で回避してたりするんだけど、外からはそんなことは見えない。

  • 抽象データ型は、「内部的に持っている実装と、外部的な仕様の宣言を分ける」という考え方。
  • ドメイン駆動開発もこの考え方が大事。
  • 内部のデータ表現は、ドメインオブジェクトが内部に持つ。
  • やりたいことだけシンプルに書いたメソッドを外に公開する。


モジュール性の比較 (P.15)
  • バートランド・メイヤーの比較表に、増田さんのバイアスをかけた表。
  • 「機能分割」は、分解しやすいかもしれないが、他の指標がどんどん悪化していく。
  • 「抽象データ型」は、関心ごとにモジュール化する。わかりやすさや連続性に結びついてくる。これがオブジェクト指向の良さの活かし方。


オブジェクト指向のモジュール性 (P.16)
  • この理屈を理解するのが大変。
  • オブジェクト指向らしいコードを書いてみて、変更が楽、という実体験をするのが良い。体で覚える。
  • DDD本の10章にある6パターンは、「オブジェクト指向エクササイズ 9つのルール」の別の切り口。非常に実践的で役に立つ。
  • お客さんから中盤で仕様変更が来ても、全部無駄になる、ということがない。
  • 機能分解でやってるよりも、オブジェクト指向でやってるほうがメリットが具体的なのでは。


オブジェクト指向エクササイズ (P.18)


ドメイン駆動 しなやかな設計 (P.20)
  • 「オブジェクト指向エクササイズ 9つのルール」とかに比べると抽象的だが、今日は具体的に説明する。


ドメイン駆動設計 (P.24)
  • 1~3章が基本。
  • ドメインを学んで、言葉で会話して、コードに落としてみるのが1~3章。


実際にどうやっているか (P.25)
  • asoviewさんの事例を紹介する。日本最大のレジャーサイト。
  • 初日の打ち合わせで、「レジャー」とか「プラン」などの言葉を彼らが使っていて、最初、ん?と思った。
  • 最初、ヘルプを見ると、よくある質問が書かれたFAQがあって、「会員登録」とか、いっぱい言葉が出てきていた。
  • あと、利用規約のページを見た。
  • asoviewの利用規約は良く作られていて、ドメインそのもので、キーワードが書いてあった。
  • 用語の定義があった。クラスの候補で、どんな振る舞いをしたらいいのかが示唆されていた。
  • ヘルプ利用規約で、ドメインの知識をすごく学ぶことができた。
  • asoviewさんは、ビジネスとシステム開発が近い。
  • 社長の天野さんは、「システム開発はお客さんのためだ」と言い切っている。
  • ドメイン駆動設計にチャレンジしたいのならasoviewさんはおすすめ。
  • 経営者が「システムが価値を生み出して欲しい」とストレートに要求してくる。


全体図+用語の洗い出し (P.27)
  • ヘルプ利用規約を読んだだけでなく、ホワイトボードに書き出した。
  • 時間的には、30分よりもうちょっとかけたくらい。


言葉を関連付けた初期のクラスのラフスケッチ (P.28)
  • その手書きを整理して初期のクラスのラフスケッチを作った。
  • このへんでドメインエキスパートと話しながら、言葉を使いながら、その言葉がぴったりくるのか、怪訝な顔されるのかを見る。
  • 会話をしながら、言葉の関連付けとか関連線の妥当性をチェックしていくのが、ドメインを学ぶということ。


コードに書いてみる (P.29)
  • 次に、コードに書いてみた。
  • 初日にクラス図をすぐ書いてみた。


とりあえずのひな型:8点セット (P.30)
  • まずPlanがあって、詳細クラス(PlanDetail)を作る。
  • 予約する行為があるので、プランの検索条件(PlanCriteria)がオブジェクトで、それでプランに一覧(Plants)を作って、と。
  • DBに予約するとかするから、リポジトリ(PlanRepository)を作って。
  • あまり考えずに、雛形のコードはぱっと書く。どんどん後で変更していけばいい。
  • 変えていくという前提で、雛形のクラスは作って始めたほうがクイックスタートできる。
  • 大体アプリ作るときは、いきなりこの程度はコードを書き始めて、頭がごちゃごちゃしてきたら、スケッチしてみて、コードを書き直す。
  • コードドリブン。


これらについて「名前」を探す (P.32)
  • 「ひと、もの、こと」という関心があって、それに対し識別の情報とか数量とか説明とか状態とか、性状(aspect)を表現する。
  • 契約とか規則というパターンがあって、「ひと、もの、こと」の関係を捉えることでビジネスルールが詳細化される。
  • 約束が履行された、されなかったはビジネスの根幹なので、記録と参照がある。
  • あと通知しあって送信しあう、とか。
  • こういうマップでオブジェクトを見つけに行ったりとか、分野ごとによく使うクラスの構造パターンが経験値としていくつかあって、それを引き出しにオブジェクトを見つけに行く。
  • とくに人。「もの」とか「こと」と違って、意志がある。特別な関心事。


関心事:3つの対象/6つの関係 (P.33)
  • 6つの関係(ヒト⇔モノ、モノ⇔コト、コト⇔ヒト、ヒト⇔ヒト、モノ⇔モノ、コト⇔コト)を書く。
  • 「この関係が抜けてるからうまくいかないんじゃないか?」のように見る。


性状(aspect):知りたいこと (P.35)
  • 知りたいこと、関心ごとを表す値。
  • 1個1個が文字列型とか数値型なので、それを包んだオブジェクトをつくる。


whyの設計パターン (P.36)
  • 契約
    • 複数の事業主体が約束する。コミットメントする。双方向の約束事。
    • そういうオブジェクトを捉えてモデリングする。
  • 内部的な約束だと、「いつまでに何をする」として、それまでにアクションして、やった、中断した、などがずらっと並んで、それをトラッキングするのがドメインをうまくドライブしていくこと。
  • 重要なのはポリシーとか方針、といった規則。
  • ポリシーはルールの集合体。ステータスがどうなったとき、とか、ルールがだんだん複雑になってくる。
  • 過去の経験を引っ張り出しながらクラスを使っていく。最初は生の言葉を使って、あとから名前を変えていく。
  • 最初からいい名前を見つけようとすると大変なので、最初は借りの名前で設計していく。
  • ドメインの一般化されたパターンであれば、どっかに当てはまるんだなぁ。


ドメインオブジェクトの見つけ方:まとめ (P.38)
  • 語彙を増やす
  • 関連付ける
  • 初日からコードを書く
    • クラスの雛形を書く。中身は書かないので最初はスカスカ。


ドメイン知識を記述する (P.40)
  • ドメインの知識を記述したとき、データもモデルも一体化する。
  • 中身の実態は、突き詰めればプログラミング言語で扱える基本データ型に対するロジックを書くことになる。
  • これをどういう単位でモジュール化するかが大事。


オブジェクト指向エクササイズ (P.41)
  • ここで登場するのがオブジェクト指向エクササイズ。
  • 3.すべての基本データ型をラップする
    • 1つのstringを取り出して、それをラップする。すべての基本データ型をラップする。
    • この3.と7.「1つのクラスにインスタンス変数は2つまで」の両方を実践したとき、相当小さいオブジェクトがたくさんできる。
    • ことごとくオブジェクトになる。それがオブジェクト思考のモジュール性を活かす良いアプローチなんだ。
    • ここまでやったほうが、今まで見えなかったオブジェクト指向の良さが見えてきたのでおすすめ。


getterを使わない (P.42)
  • 9.「getter/setterを使わない」で、特にgetterを使わないのが、オブジェクトをどこに置くか、というのに関わる示唆に富んだルール。
    • getterを使わないということは、内部に持ってるstringを他のオブジェクトが入手して加工計算できないということ。
    • 他のオブジェクトではなく、自分自身に計算とかをやらせるのが基本。


主役は値オブジェクト (P.43)
  • 加工とかはそのオブジェク自身に担当させる。
  • 名前をうまくつけることで、ロジックを引き寄せる。
  • 「あ、これはあそこにおいといたほうがいいな」と、名前とロジックが洗練される。
  • たくさんオブジェクト作ると雑然とすると思いきや、重複が激減するようになった。
  • ちょっとした式はどこでも書けちゃうのでちらばりやすいが、オブジェクトに持たせると、変更になったとき、そのオブジェクトだけ直せばいい。

ドメイン知識の置き場所 (P.44)
  • 文字列を持ったところに判断ロジックや加工ロジックが同居する。
  • そのロジックを外から呼び出す。

ドメイン駆動 しなやかな設計 (P.45)
  • 「意図の明確なインタフェース」というパターン名は、判断とかするメソッドはわかりやすくしようね、ということ。
  • 3.の「表明」バートランド・はメイヤーの契約設計。
  • 6.の「閉じた操作」は、メソッドが返す型、受け取る型を自分と同じ型にする。


ドメインオブジェクトの作り方 (P.46)
  • 重要なのは、公開メソッドを少数に限定して、メソッド名で意図を明確にすること。
  • 整数は21億扱えるけど、そんなに使わない。なので1000に制限したオブジェクトを新しくつくる。
  • やりたいことだけやるメソッドにする。範囲を限定する。
  • 数字や日付は、不正な計算とか例外が発生しやすい処理ができてしまうので、事前条件とか事後条件をいかに明確にするかが大事。
  • まずはnullはもどさない、渡さないことにすることで、if文がいらなくなる。
  • 渡しても役に立たないんだから、それをルールにすることで安定する、というのがメイヤーの考え方。
  • チームでルールにしよう。
  • 約束をいかに明確にしておけるか。
  • 表明を使ったり例外を使ったりしてやったりするが、明確にしましょう。


値オブジェクトの設計 (P.48)
  • インスタンス変数は生成時に設定する。
  • setterを置かずに不変にする。
  • getterを持たない。自分で加工してから渡す。


コード例: UserIdentify (P.51)
  • ユーザを識別するUserIdentityクラス。
  • メールアドレスでユーザを識別しよう。
  • stringでアドレスを持たせる。
  • 完全コンストラクタにするため、アノテーションでnullを渡せないようにする。


コード例: DateOfBirth (P.52)
  • 日付をLocalDateで見るようにする。メインで持ちたいデータはこれ。
  • 入力値を保持する変数sourceと、有効だったのかを保持するisValidというメソッドとフラグvalidを持つ。
  • LocalDateはなんでも入ってしまうので、型で制限する。
  • 日付でデータを保持するが、本当に注目すべきは年齢だったりする。
  • 年齢の処理もDateOfBirthに持たせるとごちゃごちゃするので、Ageクラスに任せる。


形式的な隔離 (P.55)
  • パッケージはレイヤー化アーキテクチャどおり4階層(application, domain, infrastructure, presentation)で分けてる。
  • すべてがドメインオブジェクトを使うようになっている。ドメイン層ではモデルが機能を使うようになってる。


形式的な隔離:お約束 (P.57)
  • 雛形があって、Spring Bootだと、コントローラは@controllerとか、アノテーションで書いておくと、書くべきロジックがなくなってスカスカになる。
  • お約束のパターンでさくっと書ける。
  • ドメインはバリデーションのアノテーションを使って、あとはクラス単位にはほとんどアノテーション使わない。
  • 上の4つ(コントローラ、アプリケーション、データソース、データマッパー)は、ControllerでSpringが面倒みてくれるので、ほとんどコード書かなくて良いはず。
  • でも上の4つにifとかロジックが入ってくると、ドメインロジックが流出している。
  • ドメイン層以外はできるだけシンプルに、お約束だけで済ませるべき。


オブジェクトの世界/フラットな世界 (P.59)
  • ドメインの世界はグラフ構造。末端の値オブジェクトが実際の基本データを持ってる。
  • テーブルとか画面とかjsonはグラフを嫌う。なので基本データ型を並べるリスト構造となる。


ドメインロジックをほんとうに隔離する (P.60)
  • ドメイン層をオブジェクト指向でやる、というのは左のグラフ型を作るということ。
  • 右のフラット構造に左のグラフ構造が引っ張られると、制約が出てくるし道を外す。
  • 右はフレームワークやマッパーにまかせて頑張る。左が右に引っ張られてはならない。
  • jsonに合わせたコードを作るほうが楽だが、それだと右に引っ張られた状態になってしまう。ここはこだわらないといけない。
  • 左と右を分離できるなら、そのあいだのインタフェースを多少頑張るのは仕方ない。


フレームワークの都合を排除する (P.61)
  • MyBatisは、nullはマッピングされないので注意。sqlでnullで帰ってきたものはマッピングされない。
  • MyBatisとSpringは同じ挙動になるよう設定している。

ドメインオブジェクトの育て方のシナリオ (P.65)
  • 最初は雛形を作るので、スカスカな状態から始まる。
  • それじゃアプリにならないので、ロジックを追加していく。
  • 雛形に置き場所を吟味しながら書いていくのが理想的だが、1週間のスプリントで2.を吟味してやってくと間に合わない。
  • なので、納期があるので、てっとりばやく書いちゃう。
  • コードがごちゃごちゃして整理するタイミングが、ドメインが育つポイント。
  • getterは現実として書いちゃう。そこを中心にメソッドに抽出して名前を付ける。


ロジックを整理すべき兆候 (P.66)
  • ロジックを整理すべき兆候は、本に出てくる「リファクタリングの嫌な臭い」の4つ。
  • 1.コードの重複
  • 2.長いメソッド
  • 3.長いクラス
    • オブジェクト指向エクササイズ的には、50行を超えたらアウト。
    • valueオブジェクトに分けて行くと小さくなる。6行とかにならない。5行以内。
  • 4.引数の多さ
    • 引数は2個以上渡す必要があるなら、ドメインの置き場所がずれているんじゃないか、と思ったほうがいい。


メソッドの抽出 (P.68)
  • 空行があったら、その単位でメソッドに抽出できるかを考える。
  • 改行を入れるのは楽だが、メソッドに抽出するとなると名前を考えないといけないので大変だが、ここを頑張ることで、新しい発見に繋がる。
  • いい名前が見つからない場合は、改善したくなる。そこでドメインの知識と語彙がだんだん増えてくる。
  • いい名前が見つからないでも抽出することで、学びが得られる。
  • いい名前が見つからないからといって残したままにすると、何も学びは得られない。
  • 丁寧に地道にやっていくと、ロジックの移動がごく自然にできるようになってくる。


クラスの抽出とメソッドの移動 (P.69)
  • インスタンス変数は2つまで。増えたら分けましょう。
  • グループを見つけたらクラスに抜いて、そこに加工などのロジックを移動させる。
  • クラスに抜き出したあとにメソッド名を考えるほうが、名前が見つからない状態で名前を考えるより楽。


一時変数を値オブジェクトに (P.70)
  • ここまでやるのは大変かもしれない。
  • 式を見つけたら、ぽんっとオブジェクトにして、それに何かやらせるようにする。
  • そうやると、加速度的にいいオブジェクトが見つかる。


長いメソッドをオブジェクトに (P.71)
  • メソッドをほぐしてオブジェクトを分解しやすくする。


区分オブジェクト (P.79)
  • 料金区分はenumで宣言しておく。
  • if文なしで金額計算ができるようになる。


振る舞いを豊かにするメソッド候補 (P.82)
  • スカスカの状態から振る舞いを豊かにするメソッド候補。
  • Javaの標準ライブラリにあるようなメソッドもある。
  • 型としては、こういう挙動を持つべき、というhaskellの思想を参考にしている。


第10章 しなやかな設計:6つのパターン (P.84)
  • 正直言ってわかりにくい。抽象度が高い。
  • 6つのパターンは、チェックリストとしてはよく使える。
  • 「概念の輪郭」が、業務の関心事と一致しているかいつも関心を持って欲しい。
  • 「独立したクラス」は、いろんなjarをかき集めないと動かない、というのはダメということ。


ドメイン駆動設計への道 (P.92)
  • DDDができない理由をおっしゃる方がいるが、ドメイン駆動設計へ進む気があるなら、XP本のケントベックの言葉を伝えたい。
    • どんな状況でも改善できる
    • どんなときでも「あなた」から改善を始められる
    • どんなときでも「今日」から改善を始められる
  • どんなときでもドメインの言葉で話すことはできる。だれも止めることはない。
  • どんな時でもドメインの言葉をコードに反映できる。
  • コードを書くことが仕事である以上、コードにドメインを反映できるチャンスがある。
  • 明日からでもできる。


Q&A



Q&A 1


Q.
ドメインオブジェクトを見つけたタイミングでクラスにしていくのに2点課題があると思っている。
1.ドメインオブジェクトは最初洗練されてないので変えたくなる。後でやるとリファクタリングが大変。
2.クラスが多い時に、レビューが大変。GitHubのプルリクで何十ファイルもあると嫌がられる。

A.
2.で、レビュー体制は障害になるかもしれない。
レビューって何のためにしてるのかな。
クラスの置物を考えているだけでも、その人がどのくらいドメイン考えているか、を見られる。

1.で、リファクタリングは問題に感じたことは無い。InteliJ IDEAは最高。IDEツールにより可能になったことは素晴らしい。
どんどん実験してどんどん修正できるようになったのはIDEツールが助けてくれるようになったのがでかい。

Q&A 2


Q.
細切れにする、がテーマだったと思うが、プリミティブなものがたくさんでてくるのか。
コンテキストを超えて使いまわしたいときはコピーするのか?

A.
共通モジュールにするとメンテが大変。
なので、そのコンテキストの中で成長路線に載せたほうが楽。共通モジュールにすると費用対効果的に今では大変。

Q&A 3


Q.
モジュールの依存性があると、テストが大変だが、どうすれば。

A.
そんなに依存関係が深くなるなら、テストの前に、そこを改善すべきでは。
ドメインコードに対するテストコードは書いてない。コンパイラがOKだしたらOKとしている。
サービスレベルとかではテストする。E2Eのテストも書く。
ドメインオブジェクトを切ったテストは価値をあまり感じていない。
DDDはリファクタリンクしまくるので、テストコードを直すのも大変。
テストを否定しているわけではないが、私はそうやっている。


感想


増田さんのDDDの講演は何回も聴講してきたが、毎回新しい話があって、毎回新しい発見がある。
それだけ引き出しが多くて、経験に裏打ちされたネタが満載ということなのでしょう。

今回一番興味深かったのは、P.30の「とりあえずのひな型:8点セット」ですね。
これって、今回初公開ネタなんでしょか?
この8点セットの詳細が聞きたいなぁ、と思いました。

毎度ネタ満載で、一度スライドを読むだけでは消化しきれないので、も一回復習しよう・・・

増田さん、関係者の皆様、ありがとうございました。

「JJUG CCC 2016 Spring」に参加しました。

2016/5/21(土) 「JJUG CCC 2016 Spring」に参加してきました。

DoorKeeper
https://jjug.doorkeeper.jp/events/43045

公式サイト
https://jjug.doorkeeper.jp/events/43045

場所は新宿の「ベルサール新宿グランド」です。
参加者は800名くらいあったのでしょうか。DoorKeeperの申し込みが1200名を超えてましたね。

JJUG CCCは半年に1回の大イベントですが、ここ数年、ずっと参加してます。
今年も楽しんできました。

以下、自分の復習のための当日メモ。



Type Annotation for Static Program Analysis


Type Annotation for Static Program Analysis from Yuichi Sakuraba

E-1のirofさんのテストの講演を聞きたかったのですが、部屋が満員だったので、次に今日にがある桜庭さんの講演を聴講しました。

P.11のコード例
  • equalsメソッドをオーバーライドしているが、Hashがない。

P.13のコード例
  • executeメソッドでgetMessageメソッドの戻り値のnullチェックをしてない
  • → NullpointerExceptionがthrowされるが、FindBugsは検出してくれない。
  • FindBugsは静的コードチェッカーなので、振る舞いまではあまり役に立ってくれない。
  • アノテーションでチェックできるのにチェックされてない

Nullチェック (P.14)
  • @NonNullはEclipseで使える。
  • @NotNullはInteliJ IDEAで使える。
  • これらのアノテーションはJava標準ではなく、IDE依存なので注意。
  • アノテーションをつけると、ある程度、ふるまいをチェックできる。

P.16のコード例
  • TはNonNullなんだよ、と指定したい。でも、@NonNullと全部の引数につけるの大変。
  • クラス宣言の箇所に@NonNullを付けられるが、Java SE7までこれはできなかった。
  • →type anotationが出てきた。

Annotation (P.19)
  • アノテーションの定義できるところは8種類。
  • anotation_type =メタアノテーション
  • 8種類に共通しているのは、「全部、宣言につけることができる」ということ。
  • 宣言で定義したものを使うときには、アノテーションはつけられない。

Type Annotation (P.21)
  • Java SE8で型アノテーションが出てきた。
  • コードチェックをしたいけど、今までは宣言のとこでしかアノテーションを書けなかった。
  • 宣言のトコだけでなく、使用するトコにもアノテーションを書けるようにして、ふるまいもある程度チェックできるようにした。

JSR 308:  Annotation on Java Type (P.22)
  • 既存に8種に加え、type_useとtype_parameterが追加された。



ブラウザテストをサクサク進めるためのGeb実践入門



テスト関係の勉強会でよくお会いする高橋さんの講演を聴講しました。

Geb
  • 「Seleniumu実践入門」の本にGebの章が1章ある。
  • Gebの読み方は「じぇぶ」。「げぶ」じゃない。
  • Groovy製のブラウザオートメーションツール。
  • パフォーマンステストはGebじゃなくてJmeterを使えばよい。

Why
  • Scrumをやってて、Gebでテストがちゃんと動く、というのを見せたくてGebを導入したのがキッカケ。
  • あとで、微妙だったな、と思った。
  • シナリオをカバーしようとすると、重複する。テストシナリオが重複しちゃう・・・
  • ある時、テストが一度に壊れることがあった。
  • やりたいのは、シナリオをカバーするより、バグが出ないようにしたい、という点。なので、機能テストに書き直した。
  • やってるうちに新しい知見が出た。
  • なぜ自動テストやりたかったのか、という点は、定期的に見直したほうがいい。

Where
  • 全部テストしたい = 将来的に脆いテストになる
  • どこにテストを書くかを検討しないといけない。
  • システムテスト自動化標準ガイドにGebについて書かれている。
  • 後ろの方の描き下ろしにGebが使われている。Gebの応用をやりたい、という人は読むとよい。ただし初心者向けじゃない。

How
  • 自動化ツールはいくつかある。
  • SelenideはPure Javaな自動化ツール。FluentもJava。
  • どのツールを選ぶかの指針は、今使っている技術との親和性で選ぶ。
  • GebはGroovyなので、Javaとの親和性はSelenideやFluentよりは劣るので、Javaエンジニアには学習コストがかかる。

ポイント
  • ドキュメントの量も大事。
  • Gebはドキュメントが圧倒的に多い。読むとわかる。
  • SeleniumuのAPIは辛いところがある。なので自分でラッパーを書いた。
    • それで、自分がドキュメントになってしまった。
    • その結果、ほかの人から「わからないから教えて」と聞かれまくるハメになった。
    • ググれる、というのは大事。自分がドキュメントにならないこと。

頼るなら公式
  • 公式サイトは英語だが、動作するコードの例がたくさんある。

extends GebReportingXXX (P.46)
  • reportとつくクラスを継承していると、reportメソッドを呼び出したタイミングと終了時に自動でキャプチャを取ってくれる。

ページオブジェクトパターン (P.50)
  • 利用するコンテンツのメンテナンスを上げ、再利用性を高めるデザインパターン。
  • Gebは標準でサポートしている。Pageクラスを継承することで利用する。

url (P.54)
  • Pageオブジェクトのurlフィールドに遷移先を指定すると、そこに遷移する
  • 相対パスでurlを指定する場合、GebConfigにbaseUrlを指定しておく。

at (P.55)
  • atブロックにアサートの条件を書く。

content (P.56)
  • contentでクロージャを作る。
  • 操作のエレメントを指定する。

jQueryっぽいAPI (P.57)
  • $("div")ってやると最初に見つかったdivが取れる。

テキストマッチ (P.60)
  • メソッド名の先頭がiだと、大文字小文字を区別せずにマッチングする。例: iStartsWith

click (P.61)
  • toWaitをtrueにすると描画まで待ってくれる。SPAに有効。

どのツールと組み合わせるか (P.81)
  • 使ったこと無いツールばっか採用して連携させると、落ちた時にどこが原因で落ちたのかわからない
  • 最初は現状使ってるツール使う方が良い。

記述はシンプルを心がける (P.85)
  • 中間のエレメントを定義しておくと、親のエレメントが壊れても追随しやすい。
  • atで、今どこにいる、というのを確認するようにするとよい。

スローテスト問題 (P.95)
  • テキストマッチングは基本使わない方がいい。
  • CSS Selectornがないので、Gebがリクエスト発行する。死ぬほど遅くなる。


Jenkins 2.0


Jenkins 2.0 (日本語) from Kohsuke Kawaguchi

CIの世界でデファクトスタンダードになりつつあるJenkins。その開発者の川口さんの講演です。
次の10年を見据えたお話でした。

#1: 広がり続ける自動化の波
  • 広がり続ける自動化の波がまだ広がり続けている
  • 第1のチャレンジとして、パイプラインでの並列化に取り組んでいる。

#2: コード→○ GUI→× ステート→×
  • システムへの変更をコード化して見えるようにする。これにより、意図を記述できる。
  • ビルドの仕方をテキストで記述する。
  • スニペットジェネレーターがスクリプトを生成してくれる。
  • GitHub Organization Folderは、プルリクをあげたら自動でjenkinsでテストを走らせる機能。

#3: UIの課題
  • 頻繁に使われる部分のUIをいじる。
  • スタートアップウィザードも新しいUIにする。

#4: 「要 組み立て」からの脱却
  • 今まではJenkins単品では何もできないので、プラグインをどんどん組み入れる必要があった。
  • Jenkins2.0では、お勧めプラグインが最初からついてくる。

#5: ユーザーを守る
  • 最初から安全なデフォルトのセキュリティを導入する。
  • 後方互換性も確保する。



ネクストStruts/Seasar2としてのJava EEアクションベースMVC入門 - MVC 1.0、Jersey MVC、RESTEasy HTML -




ちょうどJava読書会でJava EE7を勉強中なのと、弊社でもJavaフレームワーク刷新中でなので、興味があり聴講しました。

コンポーネントベースMVCとは? (P.8)
  • 画面とBeanを1対1に対応付ける。

MVC 1.0では画面構築の機能なし (P.15)
  • MVC 1.0では、Viewは使いたいものを使えという思想。

JSP・Faceletsの問題点 (P.17)
  • JSPは デフォルトでエスケープしてくれないので、XSSの脆弱性の危険がある。
  • FaceletsはコンポーネントのIDが動的に変わるので、JavaScriptと相性が悪い

ビューに値を渡す (P.25)
  • 戻り値はstirngでビューへのパスを拡張子ありで書く。拡張子は必須で、ビューの種類を判断している。
  • @Injectでモデルのインタフェースを指定する。

Jersey MVCの基本的な使い方 (P.41)
  • /web-inf/viewsにビューは入れるよう、mvcの仕様で決まっている


Javaプログラマーももう逃げられない。マイクロサービスとAPIの世界


Javaプログラマーももう逃げられない。マイクロサービスとAPIの世界。 from Takakiyo Tanaka

マイクロサービスというキーワード全盛な昨今、弊社もご多分に漏れず、ということで聴講しました。
先日、鈴木雄介さんのマイクロサービスアーキテクチャの講演を聞いてブログにも書いたんですが、また違う講演者から話を聞くことで多面的に学べた気がします。
分割よりAPI化を重視、という考えは独自性があって興味深いです。
マイクロサービスアーキテクチャとRESTが同時期に注目されている理由はここらへんにあるのでしょうか。


十徳ナイフとしてのGradle

https://nbviewer.jupyter.org/format/slides/github/grimrose/JJUG-CCC-2016-Spring/blob/master/Gradle%20as%20Army%20Knife.ipynb#/

講演者の@grimrose さんが主催されてる Yokohama.groovy で、初めてGroovyを学んだ私。
そんときは書籍をターゲットに写経したりしてました。そんな繋がりでGradleにも興味があります。

この日の講演は大盛況で立ち見がたくさん。そんな私も最前列の机前のスペースの地べたに座って聴講しました。
こーゆうイベントで講演したり、エンジニアの成長を求めて転職したりと、エンジニアとしてパワーアップし続ける姿は羨ましいですね。
よく勉強会でもご一緒する @grimrose さんですが、その姿勢は俺も見習わなければならない・・・

もう知らないとは言わせない!Play Frameworkはじめの一歩




先にスライドをSpeaker Deckに公開するという気配り、初の講演とは思えない段取り。素晴らしい。
ときどきスライドに出てくる英単語の発音がとても流暢で巻き舌を駆使されてたけど、帰国子女なんだろうか。
ちなみに私、秋葉原PlayFramework/Java勉強会[読書会]というのに以前参加してたので、Play FrameworkのJava環境は一通り触ったことあります。
あれからもう2年も経ってるし、けっこー変わってるのかなぁ。

デモが興味深かったですね。
ローカルPCにチュートリアルが展開されて、そこだけ見るだけで進められる形式。

Playは後方互換性がSpringに比べてイマイチらしく、2.5は2.4の互換性がないとのこと・・・

Java Puzzlers


Java Puzzlers JJUG CCC 2016 from Yoshio Terada

青いツナギの服を来た桜庭さんと寺田さん。服装は、この元ネタにあったそうです。
ちなみにJava Puzzlersという書籍があって、日本版ピアソンショックで一回絶版したらしい。
この日は5問のJavaの問題に対し、参加者みんなで考えるという方式でした。


問題2の解決2で、桁あふれで+-が反転しないよう例外を出す機能がJava8で追加されたそうです。
問題3の解説3で、Lambda式はfinalなローカル変数じゃないとアクセスできないそうです。
でも、今回は再代入しているのでFinalじゃないとのことで、普通のLambda式ではコンパイルエラーになるそうです。
lambda式とメソッド参照には微妙な違いがある。

私は5問中、3問正解でした。5問正解した人は、桜庭さん執筆の書籍が賞品でした。

休憩時間のLT大会の一幕


20160521_jjug01.jpg

今回のJJUG CCCはお昼休みも、セッション間の休憩時間も長く取られていました。
なので昼食もゆっくり取れたし、セッション間の休憩ではLT大会が催されていました。

こーゆうの、すごく良いですね。ちなみに写真は、Jenkins開発者の川口さんによるLT。
あと、コーヒーやお茶がフリードリンクで提供されており、休憩時間は飲みながらLTを聞くことができました。


懇親会


20160521_jjug02.jpg

今年は懇親会にもスポンサーが付いたということで、なんと無料!
夕方の空腹をビールと料理で癒しつつ、顔見知りの方といろいろ会話したり、LT大会を楽しんだり。
とても楽しいヒトトキでした。

感想

朝から夜遅くまで、丸一日、JJUG CCC尽くしで楽しみました。
勉強しなければ、学ばなければ、という思いももちろんありますが、何よりも、楽しい、という点が大事ですね。
学びももちろんあるけど、こーやって1日、刺激を受けつつ楽しめるお祭りみたいなイベント、大好きです。

あと、この日も鈴木雄介さんは講演もされてて、幹事として満席のセッションに椅子を追加したりと、とても活動的でした。
この週、私が鈴木さんの講演を聞くのは要求開発、アジャイルがダメだと思う7つの理由、そしてJJUGと、私が聴講したのだけで3つの講演がありました。
すごいバイタリティ。

他の幹事さんも、とても活動的で、頭が下がります。感謝。
こーゆうコミュニティ活動がずっと続くと良いですね。

関係者の皆様、ありがとーございました。

"「アジャイルがダメだと思う7つの理由」について議論する会"に参加しました

2016/5/18(水) "「アジャイルがダメだと思う7つの理由」について議論する会"に参加してきました。

connpass
http://connpass.com/event/28977/

場所はグロースエクスパートナーズ株式会社 オープンスペースです。
参加者は80人くらいでしょうか。

このイベント、AEP読書会でいつもご一緒している藤村さんがFacebookで企画して、凄い早さで定員が埋まりました。
発端は鈴木雄介さんの「アジャイルがダメだと思う7つの理由」というブログです。
当時、けっこー話題になってましたね。私も当時読みました。


  1. 全体スケジュールにコミットできない
  2. アーキテクチャ上の無駄が生じる
  3. コーチって何だよ
  4. 変化ヲ抱擁スルために固定化している
  5. 実証主義的な説明に過ぎない
  6. 手段が目的になっている
  7. アジリティはアジャイルだけのものではない

この日は、このブログネタをテーマに改めて議論するという趣旨だそうで、7つのテーマ毎にスペースを分けて議論しました。
また、鈴木さん自身の講演もありました。


鈴木雄介さんによるプレゼンテーション


「アジャイルがダメだと思う7つの理由」について議論する会の開催にあたって from yusuke suzuki


鈴木さん曰く、アジャイルについて批判的に議論したいとも思いからブログを書くに至ったそうですが、酔った勢いもあったとか。
「7つの理由 ≒ 現場が超えないといけない壁」とのことです。
アジャイルの考え方は、「プロマネがやることをアジャイルのプロセスの中に組み込んでいる」点に着目されているようです。
計画ができないならアジャイル、計画できるならウォーターフォールの方が良い、とのこと。


テーマ毎に分かれての議論


議論したいオープンスペースに各自参加して議論しました。移動は自由です。
私は1つのテーマを議論したい、というより、7つすべての議論の内容を聞きたかったので、各テーブルを回ってました。


1.全体スケジュールにコミットできない

20150518_7reason1.jpg
  • ウォーターフォールでもアジャイルでも、途中のパスが違うだけで同じものができるのでは。
  • ウォーターフォールとアジャイルで、それぞれ向いてる向いてないがある。
  • 変化を許容できないものはアジャイルに向かないのでは。


2.アーキテクチャ上の無駄が生じる

20150518_7reason2.jpg
  • ウォーターフォールでも、アーキテクチャをしっかり決めても失敗するよね。
  • バックログだけじゃなく、インセプションデッキとかも作らないとアーキテクチャは決まらないよね。
  • アーキテクチャの無駄とは、最初にアーキテクチャを固めたのに、変化しまったことでは。
  • Twitterの開発だって、最初はRailsで後でScalaに変えたけど、Railsを採用したのは開発スピードを重視したかったからなので、失敗ではない。
  • アーキテクチャを決めるのに、最初にビジョンを決めるのが大事。(どう使ってもらいたいか)
  • 小さく失敗できたほうが、アーキテクトとして成長できる。


3.コーチって何だよ

20150518_7reason3.jpg

チームディスカッションの時、ペンを持ってないと発言出来ないルールを定めているようでした。
誰に発言権があるかを明確にする工夫ですね。


  • 第三者的な人の方が、経営者とかにズバッと意見を言いやすい。
  • アジャイルだとアーキテクチャについても小さな失敗から学べる。
  • ウォーターフォールのようにアーキテクチャの設計が1回きりだと、自分のアーキテクチャが成功/失敗したのかさえ見届けることができない。
  • 「コーチ」って言葉のイメージが、みんな共通ではない。
  • コーチは、必要になったら呼ばれる位置づけなので、監視者のイメージで、押し付けと感じる人が多いのでは。


4.変化ヲ抱擁スルために固定化している

20150518_7reason4.jpg
  • 目の前のスプリントの見積もりさえ守れないなら、信頼なんて得られない。
    • 2週間も予定どおりできないのに、半年とかのスケジュール立てても意味が無い。
  • 信頼を上げていかないといけない。変化と信頼は両輪。
  • 計画どおりに行くことが大事なのか、ゴールに到達することが大事なのか。
  • 新しいものをチームに吹き込むのは、アーキテクトが言い出すのが効果的。開発チームは顧客のためだけに頑張っていると、新しいものを入れようとする暇がない。
  • メンバーを固定すると、
    • ○: 阿吽の呼吸でできる
    • ×: 飽きる
  • 同じ方向を向けない場合、人を変えたほうが上手くいく。
  • 変化を拒絶する人に、どう変化を持ち込むか?
    • 人とか技術より、文化を変えないといけないんじゃないか。それは1人では無理なので、仲間を見つけることが大事。
  • 新人教育をアジャイルでやって、アジャイルが当たり前だと思わせるように教育するのが有効では。
  • 外部の人から「アジャイルは良い」と言ってもらうのが効果的。外圧をかける。


5.実証主義的な説明に過ぎない

20150518_7reason5.jpg
  • アジャイルってハイテンションな人が多いけど、どうなの?
  • 実証主義的に振り返るタイミングを作って改善していく。


6.手段が目的になっている

20150518_7reason6.jpg
  • お客さんから「アジャイルでやってほしい」と言われることがよくある。
  • アジャイルという言葉が広まったせいで、後から撃たれることが多くなってきた。


7.アジリティはアジャイルだけのものではない

20150518_7reason7.jpg
  • アジリティとは「意思決定から、それが届くまで」とした。
  • アジリティはアジャイル単品では無理。業務とかいろいろ関わるよね。



感想


見知った顔も非常に多く、あちこちで熱い議論が交わされていて、とても楽しいヒトトキでした。
あと鈴木さん、講演から場所の手配から懇親会まで、何もかも手配されていて、すごい行動力。
JJUG_CCCでも満席の部屋に自分で椅子を増設したりと、自分が先頭に立って行動する姿が目につきました。
こーゆう姿勢も、こーゆう盛況なイベントに繋がる一要素なんだと思います。

関係者の皆様、ありがとーございました。

「要求の変化とマイクロサービスアーキテクチャ」に参加しました

5/17(火) 「要求の変化とマイクロサービスアーキテクチャ」に参加してきました。

DoorKeeper
https://redajp.doorkeeper.jp/events/44052

場所は新宿の日本総合システム株式会社さんです。
参加者は40人くらいでしょうか。

最近、弊社でもマイクロサービスアーキテクチャがキーワードによく上がります。
個人的にも↓の本を読みつつ、MSA読書会にも参加しているところなのです。

マイクロサービスアーキテクチャ
Sam Newman
オライリージャパン
売り上げランキング: 6,391


そんんわけで、この日の講演タイトル&講演者が鈴木さんということで参加してきました。
以下、復習用に当日のメモを書き起こす。


講演「要求の変化とマイクロサービスアーキテクチャ」


要求の変化とマイクロサービスアーキテクチャ from yusuke suzuki


SoRからSoEへ (P.6)
  • SoR: 情報を記録する
  • SoE: ユーザー同士の関係を作り出す


サービス運営モデル (P.7)
  • ユーザの「価値」は複数ある。
  • ITサービスの後ろには機能(コード)がある。
  • その後ろに構造やプロセスがある。
  • 一番右の「価値」から、コーディングする、「プロセス」を決める、まで距離がある。
  • いろんな関係者がいろんな関わり方をしている。


「作る」から「運営する」へ (P.9)
  • 要求は価値から生まれる。
  • 要求を変えて価値を出す。要求も変化し続ける。


要求は変化する (P.10)
  • 変化との戦いに勝つにはこーしたらいいんじゃないか、というフォーマットをとして、マイクロサービスアーキテクチャが最近注目されている


プロジェクトマネジメントの基本 (p.12)
  • プロマネの基本、やることは4つしかない
  1. 計画する
  2. 実行する
  3. 計測する
  4. 調整する


ウォーターフォールの失敗 (p.13)
  • そもそも見積もりが正しくできてないから計画も正しくない。要員通りにできない。
  • ズレの調整が、プロマネの腕の見せ所。


アジャイルの考え方 (p.14)
  • アジャイルの誤解:計画を適当にせよ
  • リソースを固定して、期限も固定して、スコープしか調整できないようにするのがポイント。
  • → 計画が正しく立てられるように短期にする。
  • 計測:動くか動かないかで100か0しかない。
  • プロジェクトマネージャがしそうな調整ごとをプロセスに織り込んでるのがアジャイル。
  • 計画はどうせうまく行かないので調整を重視しているのがアジャイル。
  • 長期の計画を正しく立てられるのなら、wfのほうが早く確実に安く上がる。
  • アジャイルはいろんなことを犠牲にした上で、みんなで考えながら一歩一歩進む手法。
  • 技術でなくプロセスに柔軟を持ち込んだのがアジャイルの重要な考え方。


クラウド (P.18)
  • 2005~2015年はクラウドやDevOpsという言葉が中心となる時代。
  • クラウド:所有でなく利用
  • 資産から従量課金へ
  • コンピューティングリソースにおける規模の経済
  • 電力と一緒。人が発電所を持つのでなく、電力を使わせてもらってる。


ソフトウェア化するハードウェア (p.19)
  • SDx (Software Defined ..) ・・・ ソフトウェア定義されるハードウェア.
  • これが大きな変更点だった。
  • 非機能要件がコーディングできる
  • 性能を上げたいなら、サーバを足すというコマンドを実行すればいい。
  • コードを変えれば非機能要件が変わる。


Platform as as Service (p.21)
  • PaaSに特に注目すべき。
  • OSSのフレームワークを利用するのに似てる。


カナリアリソース (P.28)
  • 鉱山で鳥かごのカナリアが死んだら毒ガスが出ていると判断する。カナリア=部分的な犠牲。
  • 部分的な犠牲(カナリア)を許容することで、無停止で昼間に切り替えられる。
  • やってみればいいじゃん、という考え。いいか悪いかは別として。
  • 金融とか病院とかはできないので注意。


必要な技術群
  • ルータとかもカナリアの挙動をするような新しい製品を使う。
  • 各技術群の一番右に書いているのはNetflixが公開しているOSSである。


ダークカナリアリリース (P.36)
  • システム間連携が多いのでステージング環境でテストするのがすごい大変。
  • 連携先のモックなんて用意してられない。
  • 開発者にしか見えないリリースを、本番環境でやる。
  • 本番環境のデータを使ってテストする。


Chaos Monkey (P.37)
  • ちゃんとハードウェアがソフト化されて自動化されているかを確認する。
  • ダウンさせても影響なくいけるか確認する。
  • カオスキングコング ・・・ リージョンまるごと落とす。
  • Monky関連のいろんなツールがある。SSLチェックとか。


マイクロサービスアーキテクチャ (P.38)
  • サービス=それだけで単体で稼働する仕組み
  • APIで連携し、互いは疎結合


MSAの2つの側面 (p.41)
  • MSAの9個の特徴は技術的な話と組織的な話に分けられる。
  • 技術面: 分散配置と統合
  • 組織面: 持続性と分権


MSAの組織面:持続性と分権 (p.42)
  • ドメイン=業務、という言葉が近い
  • サービスそれぞれは好きな技術で作って良い。自主性を認める。
  • 標準化なんて意味がない。
  • 技術は多様化しているので、ドメインに特化した技術がある。
  • 尖った仕組みを作れるように。エンジニアがやる気が出る技術使えばいいじゃん。
  • ドメイン個別のライフサイクル。自分のタイミングでリリースしていい。
  • 犠牲的アーキテクチャ。どうせ変わるんだからあとで作ればいい。


変化するために分割する (P.43)
  • 変更で大変なのは事前調査とテスト。
  • サービスに分割されていれば、変更の影響はサービス内部にとどまる。
  • データベースも共有しない。


変化とサービス分割 (P.45)
  • サービスをうまく分割するのが重要。業務別にサービスを割っていきましょう。
  • サービス分割どうすればいいか、というのは正解がない。業務を知ってるあなたが考えることです。
  • 全体視点で誰がやるの?は日本の課題。ユーザ企業側に優秀なアーキテクトがいない。
  • 日本はSIerにエンジニアがいて、ユーザ企業側のエンジニアは少ない。
  • ドメインに従ってサービスを分割するのが大事。


MSAは目的ではない (P.51)
  • MSAに「する」、ではなく、「なる」
  • あなたドメイン知ってるんですか?ドメインを理解してないとMSA導入を先導できない。
  • ドメインを知らない技術屋が、MSAやりたいんです、は怖い。
  • MSAは技術論と組織論のバランスがうまく取れている。
  • 建築業界では、工法と構造はセット。itは別々。MSAで両方がセットで語られるようになってきた。


感想


マイクロサービスにみならず、アジャイルとウォーターフォールの比較などを交えていろんな視点からサービス開発を俯瞰していました。
とても勉強になります。

講演者の鈴木さん、関係者の皆様ありがとーございました。

-->