MicroAd Developers Blog

マイクロアドのエンジニアブログです。インフラ、開発、分析について発信していきます。

Scala関西Summit 2018に参加したので感想を書きます

マイクロアドのサーバサイドエンジニアの松宮です。少し時間が経ってしまったんですが、今年もScala関西Summitに参加してきましたのでマイクロアドと絡めながらつらつらと感想を書きたいと思います。 ちなみに今年はマイクロアドからも初めてスポンサードさせて頂きました!

f:id:kmatsumiya6:20181120110833j:plain

今までもマイクロアドではScalaを採用したプロダクトはいくつかありましたが、全体ではJavaがメインだったため、Scala関係のイベントへのスポンサードはしておりませんでした。しかしここ数年でApache Sparkを採用したり、主要プロダクトのScala化をきっかけに社内全体にScalaが浸透していき、その結果、今回のScala関西Summit 2018へのスポンサードができました!

Apache SparkやScalaへの変遷については以前のブログ記事で紹介させて頂いていますので、良ければご覧ください。

目次

今年はAkkaのセッションが多かった印象

さて、今年もScala関西Summitは100人以上のScalaエンジニアが集う盛況ぶりで、個人的にも興味深いセッションがいくつも聞けたので大満足でした。全体感として今年はAkkaに関するセッションが多かった印象で、Akkaへの注目度が年々増しているように感じました。マイクロアドでもAkkaを積極的に利用していますのでAkkaの話題が多い事は嬉しい限りです!

Akka関連ですと、kamijin_fantaさんの「Akka-HTTPで作るAPIサーバ」にてAkka HTTPを導入する理由について熱く語られていましたが、まさにマイクロアドでも似た理由でAkka HTTPを採用しているので大変共感できました。

speakerdeck.com

発表されていた通りAkka HTTPの単機能ゆえの使い勝手の良さが個人的には気に入っています。マイクロアドで扱うプロダクトはリッチな画面や様々なユースケースがあるようなWebサービスではないので、高機能なフレームワークは必要としていません。むしろできる限りシンプルかつ利便性の高いWebサーバが必要になります。となればAkka HTTPは有力候補ですよね!

シンプルなライブラリに拘る理由としては長期的に見た場合のメンテナンス性の維持が念頭にあります。特にScalaはメジャーバージョンが上がった場合のバイナリ互換は担保されません。そのためマイナーなライブラリや規模が大きく新しいバージョンへの対応に時間がかかるようなライブラリの採用は、先々のバージョンアップ等のメンテナンスにおいてリスクを伴うと考えられます。そこで必要十分な機能を備え、Lightbend社を中心とした多くのメンテナがコミットしている安心安全なAkka HTTPを採用したという訳ですね。

Scalaでメンテナンス性を考えることの重要さ

メンテナンスといえば、竹添さんの「長期的なメンテナンスの必要なScala製システムにおいて気をつけるべきこと」が大変参考になりました。

www.slideshare.net

話を聞く限り相当苦労されていたんだろうなぁ・・という事がひしひしと感じられるセッションでした。Javaで開発されたPlayベースのソフトウェアをScalaで開発されたPlay2に移行し、さらにPlay2のバージョンを刻みながらマイグレーションしていくという・・・。聞いただけで寒気がします・・・。尚、話の結論としては「Scalaを採用する以上は変化を楽しむべき」という大変清々しい内容となっていました。

特に最近はオラクルのJDKのリリースモデルの変更によって、JVMに依存しているScala製プロダクトのバージョンアップ戦略はより重要度を増していると感じています。例えば現時点で最新のJava11はLTS指定されたフィーチャーリリースですが、AkkaはまだJava11対応が完了していないのですぐに移行することは出来ません。そうなると当然Akkaに依存しているPlay Frameworkも利用できませんし、多くのライブラリに依存しているフレームワークは最も対応が遅れると考えられます。また、2020年にはScala3がやってきそうですし、より一層ライブラリやフレームワークの選定は慎重にならざるを得ません。

そして最後はDDD

最後のセッションではDDDについてのお話を聞きました。かとじゅんさんによる「Scalaでのドメインモデリングのやり方」です。

speakerdeck.com

特に印象的だったのが、「やかんに知性を持たせる」という話です。例えばやかんをモデリングしてもやかんは生き物ではないので現実に即して考えれば、何も振る舞いを持たない貧血症オブジェクト*1になります。しかし見方を少し変えて「やかんは沸騰を通知する機能を持つ」と考えると途端に振る舞いを持たせる事に違和感がなくなります。この発想は非常に衝撃的でしたね・・・。そういえば、いつか読んだオブジェクト指向のこころにも似たような事が書いてあったような気もします。別のところで得た知識が繋がると何か嬉しいですね。

マイクロアドとDDD

それにしてもDDDはいくら学んでもできるようになった!という実感が全然湧いてこないです。マイクロアドでは社内勉強会や輪読会を通してDDDを導入し始めていますが中々苦戦しています。各々DDDへの理解が異なっていたり、実際どちらも正解であるような場合があり、議論が平行線になりがちだったりします。結局最後は決めの問題といったシーンがあり、DDDに対する知見がまだまだ不足していることも一因ではありますが、個々人の感覚の違いが大きいのではと思っています.

例えばDDDを始めるにあたってアーキテクチャの選定は重要な要素だと思います。レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャやクリーンアーキテクチャ等々あり、さらには同じアーキテクチャでもレイヤー構成は千差万別です。それらはどれが正解でどれが不正解という訳でもなく、それらの知識を活用して適切に設計することが重要です。しかし、DDDに慣れていないとそのあたりの舵取りが難しく理詰めで答えを出しづらいので、ある程度個々人の好みとそれなりの合意で設計を進めることになります。なので常にこの設計で良いのかどうかの不安が拭えないのが現状の悩みですね。

とはいえ、実際のところはDDDを用いることでメンバー間での議論のネタができることと、DDDという柱があることで、各々がより優れた設計を模索することに繋がっているので、導入以前と比較してプロダクトの品質を上げやすい環境にはなってきているんじゃないかと思っています。

来年も参加します!

ということで、本当につらつらと感想を書いただけになりました・・・(ºДº;)

他にも様々なセッションを聴講させてもらいましたが、いずれも大変勉強になるお話ばかりでしたので来年も引き続き参加したいと思っております。また、運営の皆様方においては、このような素晴らしいイベントを企画・開催して下さって感謝の至りです。 また本記事を読んでくださった皆様にも感謝をいたします。

*1:振る舞いを持たず、値を保持するだけのオブジェクトのこと。DDDではしばしばアンチパターンとして紹介されます。