Java Day Tokyo 2015に参加してきました - たなかこういちの開発ノート

Java Day Tokyo 2015に参加してきました。今年はJava誕生20周年だそうです。下の写真は懇親会で登場したDuke's Birthday Cakeです。

私の職業人人生＝業界歴も今年（2015年）で21年目、Javaとほぼ同期だったのです。最初のJavaの仕事は1999年に「Servletは使えるのか？」という調査（※プロトタイプを作ってApache CGIと比較）だったと記憶します。。

2-3 「Applied Domain-Driven Design Blue Prints for Java EE 7」

7-4 「アジャイル時代のモデリング」

2-5 「Reactive Java EE 7 - Let Me Count the Ways !」

要素技術や個々のプラクティスは書籍やWebで学べるだろうから、こういうセッションでは大きな概念や考え方を知れるようなものを選んでいます。

■ 「Applied Domain-Driven Design Blue Prints for Java EE 7」について

Oracle社のReza Rahman氏（@reza_rahman）によるセッションです。

DDD（Domain-Driven Design）を、Java EEの要素技術で実現しようとしたとき、Java EE技術をDDDの要素にどのようにマップできるか、という話でした。基本的に下記サイトの内容をセッションで説明した、ということでした。"Cargo Tracker"とは、DDD対応したJava EEアプリケーションのExampleであり、従来Exampleとして提供していた"Pet Store"の置き換えとして位置付けられる、とのことです。

"Cargo Tracker"、"Overview"：https://java.net/projects/cargotracker/pages/Home

DDD自体の理解の仕方について概要の説明もありました。Layer構造をとるという点を強調していて、上からPresentation - Application - Domainという階層構造があって、その全ての階層に掛かるように*縦*にInfrastructure"のブロックを置く、という図示がされていました。

※その図が下記にありました。

"Cargo Tracker"、"Layers/Architecture"：https://java.net/projects/cargotracker/pages/Layers

Layer構造の観点から「Rails批判」がありました。「たしかに立ち上がりのよさはある。小規模ならよい。しかし、規模的にある閾値を越えると（"Convention over Configuration"は）とたんに立ちいかなくなる。」といった主張でした。

■ 「アジャイル時代のモデリング」について

株式会社チェンジビジョンの平鍋健児氏（@hiranabe）によるセッションです。講演資料が下記にあげられています。

"Modeling in the Agile Age"：http://www.slideshare.net/hiranabe/modeling-in-the-agile-age-jp

私は次のような理解をしました。（※以下は私の理解、解釈を記していますので、平鍋氏の本来の趣旨とは異なっている場合があります。）

アジャイルでは、高速開発を重視するが故に、全体設計をしないというイメージがあるかもしれない。別に全体設計をしない訳ではない。ただ、ウォーターフォールのようにみっちりやっても仕方がない、という考えである。アジャイルとは、サグラダファミリアのように、「常に建築中」といったプロジェクト運営方式である。まさにサグラダファミリアのように、「常に建築中」であっても全体の一貫性や見通しを持っていない訳ではない。

アジャイルの肝は「大きな設計を事前にやらない」という点である。ウォーターフォールでは「大きな事前設計」＝「BDUF（Big Design Up Front）」をやっている。対極として「事前設計無し」＝「NDUF（No Design Up Front）」がある。アジャイルはこのNDUFをしようと言っているのではなく、両者の中間にある「十分なちょうどよい事前設計」＝「ENUF（ENough design Up Front）」がよいと言っている。ウォーターフォールでは、往々にしてBDUFをやること自体が目的と化する。そのような「官僚的手続き」を廃するのであって、「モデリング」を捨てるのではない。ちなみに、受託開発ではアジャイルは難しいと考えている。

"Enough"な設計とは、「（ステークホルダーの）共通理解を得るために必要な、最もシンプルなモデルのセット」ということであり、また、コードが（直接）表現している内容と重複しない粒度以上に留めるべきで（※つまりいわゆる詳細設計書的なものは真っ先に廃されるべきで）、具体的にどういうものとなるかというと、「アーキテクチャー」と「ドメインモデル」と「キー・ユースケース」である。アジャイルにおける「アーキテクチャー」は基本的には過去の知見から得られるものと考える。それを「収穫する」という。ミドルウェアやフレームワークを選定すればそれでアーキテクチャーは決定される場合もある。ソフトウエアの“材料”は「言葉」であろう。「言葉」の関係を作るのがソフトウエアの開発ということだろう。まさにそういった言葉の関係を描いたのが「ドメインモデル」である。「ユースケース」とは“機能”ではなく利用者から見た“場面”である。「キー・ユースケース」といっているのは、全てのユースケースを描く必要はないということである。

アジャイルを大規模に適用したいという流れがある。それを「エンタープライズ・アジャイル」と称している。横展開の方法は、最初のチームが最初のサブシステムあるいはアプリケーションを“やっつけて”から、各メンバーがその知見を持って、他のサブシステムあるいはアプリケーションをやる新チームへ散っていく、というのがよい。伊勢神宮では「式年遷宮」という、20年に一度全ての社殿を造りかえるという儀式がある。（諸説あるが、）20年に一度実施することで技術伝承ができる、という意図があると言われている。全てを外部化できないので「人の記憶」が一番なのである。

■ 「Reactive Java EE 7 - Let Me Count the Ways !」について

再びReza Rahman氏によるセッションです。下記資料に基づいた講演で、「Reactive」をJava EE技術でどのようにやれるか、という話でした。

"Reactive Java EE - Let Me Count the Ways!"：http://www.slideshare.net/reza_rahman/reactive-javaee

Rahman氏の主張の要点は次の３点にまとめられるでしょう。（※度々の注釈ですが、以下は私の理解、解釈を記述していますので、Rahman氏の本来の趣旨とは異なっている場合があります。）

・世間でよく「Reactive」と言われる内容を見ると、多分にマーケティング観点から取り入れられたと思われる内容や、「Reactive」と言わずともエンタープライズ・システムには常に必要とされるだろう内容が盛り込まれている事があり、「Reactive」という用語は相当不明瞭なものとなっている。

※この言及はおそらくおおよそ「Reactive Manifesto」を指していると思われます。

・とはいえ、「Reactive」は従前よりソフトウエア・エンジニアリング上の重要な技術であったし、今後より重要となるであろうことに違いは無い。

＜従前から「Reactive」が重要だった技術領域＞

- よりResponsiveなUX

- マシンやCPUの、高スループットで最適化された利用

- 疎結合（Loose coupling）

- 複合イベント処理（Complex Event Processing）

＜今後「Reactive」がさらに重要となる技術領域＞

- IoT（Device-to-Device Communication）

- モバイル、グローバルから同時アクセスする多数のユーザー、より"Chatty"なアプリケーション

※"Chatty"とは、おそらく単に"Interactive"なだけでなく、よりリアルタイムに対話的なアプリケーション、といった意味だと思われます。Twitter、Slack、などがその典型例というところでしょう。

・しかし、非同期・イベント駆動のコードは簡単ではないことに注意。（一方で、ハードウェアはより安く、より保守容易になってきてもいるので、費用をかける箇所が変わるがトータルコストは一定枠に収まると言えるかもしれない。）

あとは非同期処理をやるための各種Java EE技術の具体的な紹介でした。JMSだけでなく、Java EE 7までに「Asynchronous Servlet」、「CDI Event」、「Asynchronous JAX-RS」、「WebSocket」といったものが揃えられている、ということです。Java EE技術による非同期処理にどんなものがあるのか、（Akkaなどに走る前に、）一通りラインナップを見ておいた方がいいと思いました。

＊

懇親会でのいただきもの。

◆以上