JJUG CCC 2019 Springに行ってきました

本日開催されたJJUG CCC 2019 Springに参加しました

JJUG CCCへの参加は2回目で前回は去年のspringに参加しました。 今回は都合で午後からの参加になってしまいましたが、聴講したセッションについて感想など整理できればと思います。

先行開発!Javaでクリーンアーキテクチャ -- ゼロから始める新規開発

成瀬さん(@nrslib) speakerdeck.com

成瀬さんのお話を直接お聞きするのは2回目で、1回目がボトムアップドメイン駆動開発の勉強会でした。

こちらの勉強会がとてもわかりやすく噛み砕いて伝えていただいた印象が強かったのですが、今回もわかりやすく理解も深まりました。

クリーンアーキテクチャのワークショップ、非常に興味あります。

私は普段の開発でオニオンアーキテクチャを意識していて、クリーンアーキテクチャの方は思想的なところは少し抑えていたのですが細かい要素が何を表しているのかは余り把握出来ていないというレベル感でした。

今回の発表の中でadapterやport, controllerやpresenterをテレビゲーム機に例えていて、イメージがしやすくそれぞれが何を指しているか掴めました。

コード例も見やすく、充実していて他の方に伝播させるときなどにも是非参照させていただきたいです。

お話の中でもありましたが、クリーンアーキテクチャの導入に際しては用意するクラスが多いので自動化ツール必須だなという印象をうけたのと、オニオンアーキテクチャはクリーンアーキテクチャの内側に相当するという説明の部分でどの層がどの層に該当するのかという辺りが気になりました。

オニオンアーキテクチャ クリーンアーキテクチャ
アプリケーション層 ユースケース
インフラストラクチャ層 インターフェースアダプタ層

私の理解では表のような対応関係を考えていたので、互換ではなく内側ということは私の理解が異なっているのでしょうか。 この辺を調べて理解深めたいです。

テストエンジニアが教えるJUnitを書き始める前に考えるべきテスト

ブロッコリーさん(@nihonbuson) speakerdeck.com

お話の仕方自体が上手な方で、今まで体験したことのないリアルタイムなアンケートやペアワークなどタイプの催しも開催されていて新鮮でした。

内容も学びになる点が多く得るものが多かったです。

私が普段書くテストは期待通りの振る舞いをすること、リファクタをかけた時に元の動作を担保することという目的が大きいです。

書いたテストも私の理解する仕様的にこうあるべきという主観で記述していたので想定していないバグを作り込んでいるではという不安がいつも付きまとっています。

今回の発表で

  • コードを書き始める前に始めるテスト活動もある
  • テストにも設計がある
  • コードレビューに勉強会もある
  • 開発者が行うのはChecking
  • QAチームなどが行うのはTesting

など今まで知らなかった世界が結構あるなという学びがありました。 コードレビューも苦手なので、興味があるので勉強会に参加してみたいです。

LINEのBot Platformの裏側

長谷部さん(@be_hase1014) speakerdeck.com

LINE チャットアプリのバックに興味があったので聴講しました。

トラフィックが大量で大規模なLINEさんならではのアーキテクチャフレームワークの話が聞けました。

社内の有志とAkkaの勉強がてらチャットツールを作ろうと動き始めていたところだったので、タイムリーでした。

SpringのWebFluxやCloud Sleuthを利用しているという話があり特に後者は普段の業務でも有用そうなので押さえていきたいです。

ストラングラーパターンによるマイクロサービスマイグレーションの勘所

川上さん(@kawakamitor0312) speakerdeck.com

先週の現場DDDでストラングラーパターンという用語を聞き、気になったので聴講しました。

レガシーシステムからマイクロサービスに移行していくに当たってのプロセスで、少しずつ切り出していく流れを話されていて参考になりました。

DB分割の仕方のところで

  • 新規機能でまずAPI経由でDBにアクセスする
  • 既存機能でDBを直接参照しているものAPIに切り替える
  • 全部API経由に切り替えたところでDBに着手する

というアプローチを取られていました。

順番についても全部を分割するのではなく、効果的だと判断できる部分から取り組むということでした。

少しずつ切り出しているのでレガシーシステムと並行稼動していてリクエストの振り分けの話もされていて実務でレガシーシステムの改修をするという場合に参考になりそうな情報が盛り沢山でした。

マイクロサービス 4つの分割のアプローチ

増田さん(@masuda220)

www.slideshare.net

先週の現場DDDに引き続き増田さんの話を聴講しました。

増田さんもモノリスからマイクロサービスに部分的に切り出していくアプローチでお話されていて、これまで聞いてきた話で概ねそのパターンなのでレガシーからの移行は少しずつが正解なのかなという印象でした。

マイクロサービスの分割の限界は経験値による → 経験を積んでいくとより細かく出来るかもしれないが最初から細分化は難しい という話が先週のDDDの話の最初から良いモデルを作るのが難しいという話と重なってくるなと感じました。

ビジネスファンクションでの分割の例が、私の業務で分割したパターンそのままで、自分たち(人間側が)がサービス単位まで分解されていなく複数面倒みることになったりや、修正取り消しうまく回らなくなるという課題があるという話が実際起きてしまっているのでかなり刺さりました。

コーディネータパターンも複数のサービスにまたがったトランザクションを考えるときにそうするしかないよなと思いつつも、メッセージキューなどが絡んでくると訂正処理もまたなかなか難しいなという実体験とリンクさせて聞けました。

全体的にかなり背景にDDDというものを意識されているように感じて、非常に楽しかったです。

BPStudy#141〜DDD(Domain Driven Design)実践の現場にも参加させていただこうと考えているので、増田さん、高崎さんのDDDのお話が聞けるのを楽しみにしています。

最後に

普段業務でJavaを使用しているのでコード例などもすんなり入ってくるという点と、CCCということで多様な分野のお話が1つの会場で聞けてお得だなという印象が強かったです。

環境面でも広い会場で運営の方もたくさんいらしゃって、Wi-Fiも提供されていたりハッシュタグも整理されていたりとかなり快適でした。

良い機会を作っていただいて、関係者の皆様に心よりお礼申し上げます。

次は是非懇親会にも参加したいです!

レガシーをぶっつぶせ。現場でDDD!に行ってきました

レガシーをぶっつぶせ。現場でDDD!に参加しました。 参加してみて、現場の生の声や体験談などなど聞けて初学者ながら良い刺激をいただきましたので熱が冷めきらないうちに感想をまとめてみました。

私の背景としては、昨年の今頃から増田さんの現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法を読んでDDDに興味を持ち、現在業務に導入できないか検討しているというレベル感です。

ソフトウェアの核心にある複雑さに立ち向かう / ビジネスルールの複雑さに立ち向かう

増田さん(@masuda220)

アプリケーションが複雑になるのは、ビジネスルールを適用するの条件に分岐が出てくるから複雑に

心当たりがあります。コーディングしていて複雑なビジネスルールがあるところは読み解くの大変だったり汚くなりがち… うまく記述していかないと、ほぼ使われないオプションのためにあらゆる箇所に新しいフィールドを加える…といった残念な設計に…

入出力と計算の分離

変換部分でなかなかコストがかかるなというのはDDDをかじっていて思う部分ではありますが、そうすることで計算モデルを純粋に保てるというのはまさに良い恩恵かなと思います。 逆にそこにあまりメリットが感じられない人に対してこの変換の手間を納得してもらうのもなかなか大変だよなぁと公演を聞きながら考えていました。 後のパネルディスカッションでもお話ありましたが巻き込んでいける人とそうではない人との関わり方をうまくハンドリングしていくのもDDDをやる上ではかかせないのかも…

型指向プログラミング

値の取り得る範囲での生成を強制することで安全に値を取り扱えて防御的プログラミングならず、コードがビジネスの本質に集中できるというのは現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法を読んだときから共感する部分でした。 テストについてはリファクタかけたときに元の仕様担保出来ていることを確認するため私は用意するのですが、値オブジェクトのテストは一般的には自明なので書かないのかな… また、どの粒度まで値オブジェクトとして用意するかという部分が悩むところではあって、例えばお金を取り扱う業務があったときに取り扱う金額の範囲でMoney型を定義するのはもちろんとして、数量を表すAmount型も合わせて用意するべきなのか、もし用意する場合は他の数量を取り扱うようなAmount型を使いまわして良いのか(Util, 共通モジュールのような取扱にならないか)でよく悩みます。

複雑さに本格的に立ち向かう

言語化できないもやもや(新しい概念)にうまく名前をつけられたときに、他の複雑さを持っていると整理していた部分についても同じ区分で表現でできることがわかりより良い整理ができる。といった体験があったため共感する部分でした。 コレクションのカプセル化の部分で、カプセル化したクラスに特定の操作やロジックがあるものはビジネスルールがまとまって扱いやすいので共感できる部分でした。 一方でコレクションクラス化を進めているとロジックが内部の値にアクセスするだけの貧血起こしているクラスも出来てきて、そうならないための切り分けや判断材料等など聞いてみたいと感じた次第でした。

抽象的な教えを試行錯誤しながら解釈したDDDの実践レポート

ほげさん(@suzuki_hoge

何やらレビュー時に抽象的なフレーズが飛び交っている

入門してすぐがDDDの用語に圧倒されるというのはどこでもあるあるなのかなと感じました。 例に漏れず私も圧倒されているので松岡さんのブログ成瀬さんのボトムアップドメイン駆動設計勉強会に非常に助けられています。

名詞の抽出

名詞同士の関係性まではなんとなく見えてくるものの、振る舞いがよくわかっていないままコードを書く → アプリケーション層やインフラ層が膨らむ & モデルが貧血起こしてGetterだけあるという状態に私も陥りました 同じ流れたどっていて入門者あるあるなのかなと感じていました。

ドメインに集める?

私の場合はDB操作はインフラ層に持っていっていたものの更新のための判定ロジックも一緒にインフラ層に散っていたり、それぞれのRepositoryに永続化を依頼するため条件がアプリケーション層に散っているといった状態です。 ほげさんの取られていた動詞に着目してinput param → prosess → output paramの形を徹底的してドメイン層にロジックを集めていくというアプローチは目からウロコでした。

境界を決める

知りすぎているドメインを切断した流れが、Evans本の独立したクラスに当たるのかなと考えながら聞いていました。 私がまだ実践できていない部分なので今聞けてよかったというのと、事業戦略を考慮して変えたい願った部分だけを変えられるよう設計するという言葉が強く印象に残っています。

DDDサンプルコード ライブリファクタリング

いろふさん(@irof) 増田さん(@masuda220) https://github.com/system-sekkei/isolating-the-domain

どういう意図でサービスを呼んでいるのかというのを明示的にするためにControllerからCoordinatorというクラスを作成しそこに操作の組み合わせを記述していくというものでした。 機能を変更するときの影響箇所の特定が簡単になるので安心というのがいいなという印象でしたが、あまり多用すると私の場合はビジネスルールの関心事も外のCoordinatorに流出させてしまいそうな気がしたので、採用する際はビジネスルールなのかシステムの都合なのかを慎重に判断した上で操作を記述すべきだと感じました。 Jigというツールや1つのパッケージのファイル数max10個ルールなど実践的な話を生で聞けたのも収穫でした。

劇的ビフォーアフターBIGLOBEのDDDの昔と今〜

曽根さん

のれん分け方式

リードしている人だけでなく暖簾が分けられるほど他のメンバーも成熟して行けているのが凄い成果だなと。DDDに限らず新しい技術の伝播するのに良いなと感じました。

Pull Requestが大荒れ

Beforeの部分でプルリクのコメントでそもそもの責務の話から入るのエネルギー奪われて気が滅入るなと…辛い…

状態の表し方

ファクトリで状態の加工処理を行っているというのが勉強になりました。

チェック

チェック処理をドメインサービスにまとめているという話が新鮮 Applicatin層にチェックロジックが漏れていく話はほげさんのお話聞いているときも私やりがちだなぁと感じていた部分ではあり、あるあるなのかなと。 ドメインサービスはチェック項目毎にドメインサービスを作るイメージなのか気になりました。

実録!LOHACOにおけるDDDとCleanなArchitecture

さとうさん(@dskst9) なかむらさん https://speakerdeck.com/askul/ddd-and-clean-architecture-at-lohaco

ストラングラーアプリケーションパターン

そういう名前がついているんですね。ワードを初めて聞いたので勉強になりました。

抽象的であっているかいないかもわからないままやっていくしかない

結構いろいろな方がこの状況に遭遇して日々手探りしている部分ではあるのかなと感じました。手探りでやっているのは自分たちだけじゃないという話を聞けただけでも収穫でした。

コードが語り始める

そのレベルまで進めて行けているのが素晴らしく、よりコードが自然言語の振る舞いに近づくとそうなる?

Web層

モジュールの構成でインフラ層の配下にWeb, DB…のようなモジュールを私の場合切ってしまいそうで、あえてインフラとWebを別物として切り分けているのが印象的でした。

質問:振る舞いではないのでGetter書きたくないがほかレイヤへの情報の開示どうしているか?

利用する側に内部の情報を展開するためだけにGetterを書きたくない(振る舞いではないから)というのは私も同じことを思います。 私はJava, Springで開発する機会が多く、増田さんに質問する機会があったのでこの問題に対してどうされているのかお伺いしたところSpringのDirect Field Accessを使っているとおっしゃっていました。 かとじゅんさんの記事でもこの問題に触れられていますね。 一般にはどうするのが良いのでしょうか。

おわりに

参加して良かった、同僚にも次があればぜひ行こうと言える充実した内容でした。 皆様の話を聞くとレガシーを潰そうというよりもうまくレガシーと付き合っていっているというように印象が強かったです。 技術的な用語や内容にフォーカスされがちだけど、それだけがソフトウェア開発やDDDじゃない。人付き合いを始めとしたコーディング以外の戦いの場(むしろそちらのほうが主戦場かもしれない)もあるとひしひしと感じました。 今回の勉強会を企画、運営してくださった方々、登壇者の皆様、参加させていただき誠にありがとうございました