とはいえ、なかなか Reactive なシステムを開発する機会がなく、RSocket や R2DBC などは未だに試せていない状態です...。GraalVM とかかなりホットな話題なので素振りしておきたいところ。以前、ちょっと触ってみた Micronaut あたりで GraalVM を試してみようか。もしくは Quarkus あたり？

あと、Moduliths はなかなか面白そう。アーキテクチャをテストできるという意味では、JJUG CCC 2019 Spring で紹介されていた ArchUnit と近いものがあるんだろうか。

JJUG CCC 2019 Spring に行ってきた #jjug_ccc - kntmr-blog

以下、メモから抜粋。(2019/07/02: 資料のリンクを追記しました)

Spring Framework のロードマップと 5.2 の新機能

Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能 from Takuya Iwatsuka

www.slideshare.net

Spring 5.2 は 9/4 GA に延期
5.x で取り入れた機能のアップデートがメイン
Reactive API
- RSocket (マイクロサービス間の通信)
- R2DBC (RDBMSへのリアクティブアクセス)
R2Socket
- L7のバイナリプロトコル (HTTPと同じレイヤ)
- Reactive Streams (Backpressure)
- 4つのインタラクションモデル (片方向/双方向、Mono/Flux)
- spring-boot-starter-rsocket
- @MessageMapping
R2DBC
- RDB のドライバ用の SPI を定義
- Spring Data R2DBC
- リアクティブトランザクション
- 従来のトランザクション処理と同じように使える
- ただし、裏側の実装は全然違う
Reactor のデバッグ出力を改善
- トレース生成のコストは高い
関数型 API の整備
- Router Function が MVC で使える
Spring 5.3
- JDKアップデートに追従 (13-15)
- Code Analysis Annotations
  - @Nullable？
- GraalVM
Spring 5.x で対応されないもの
- Java 11 ベース
- モジュールシステム
- Jakarta EE (javax パッケージ？)
- Project Loom

Spring 5.2 の Kotlin 対応

SpringIO2019報告_Kotlin関連 from ShingoKurihara1

www.slideshare.net

Coroutine 対応
- WebFlux 向けの機能をサポート
- ReactiveX に替わるものではない
- Reactive と Coroutine は同じように使える
Spring Kofu
- Experimental
- Functional Configuration
- アプリ起動の高速化、省メモリ

GraalVMの概要と、Native-Image化によるSpring Boot爆速化の夢

GraalVM の概要と、Native Image 化によるSpring Boot 爆速化の夢 from apkiban

www.slideshare.net

Graal コンパイラ
- JIT コンパイラ
- Java で実装されている
- 最適化技術が改良されている
Truffle
- 言語インタプリタの実装フレームワーク
- Javaから他言語を簡潔に呼び出せる (Polyglot)
Native Image
- JVM 言語を AOT (Ahead-of-Time) コンパイルしたもの
- VM が組み込まれており、スタンドアロン起動可能
現時点ではそのまま Spring Boot アプリを Native Image にはできない (制限が多い)
- リフレクションや Dynamic Proxy で動的なクラス生成を多用しているため
Spring 5.3 で Native Image に正式対応予定
今のところ Native Image のビルド時間は非常に長い

Spring Cloud Netflix

What happens in Spring Cloud Netflix from apkiban

www.slideshare.net

ほとんどがメンテナンスモードに
- 脆弱性やバグfixは Pull Request で対応
Ribbon ⇒ Spring Cloud Load Balancer
- アノテーションを切り替えるだけ
- WebClient が使える
Eureka ⇒ Spring Cloud Zookeeper
- メンテナンスモード対象ではない
- 移行パスを検討中
Zuul ⇒ Spring Cloud Gateway
- アノテーションが不要に
- 明示的にルート定義が必要
Hystrix ⇒ Spring Cloud Circuit Breaker + Resilience4j
- アノテーションが不要に
- Circuit Breaker は様々なサーキットプレイカーを使えるように抽象化したもの
Hystrix Stream, Turbine, Hystrix Dashboard ⇒ Micrometer + Prometheus
- メトリクス情報を収集して監視ツールにエンドポイントを提供する
Archaius ⇒ Spring Cloud Config Server
- そもそもアーキテクチャが違う
- Archaius は各サービスがプロパティを取得するためのエンドポイントを提供する
- Config Server は各サービスにプロパティを配布して起動時にロードさせる
マイクロサービス開発を担うプロダクトは多い
- 今後、統廃合があったりするかもしれない

Spring Boot で作るいまどきなモノリス

Spring I/O 2019 Recap - Moduliths from Ogawa Takeshi

www.slideshare.net

Modular Monoliths
Moduliths
- odrotbohm/moduliths - GitHub
パッケージをモジュールで分割する (ドメイン)
main がある階層のパッケージがモジュールになる
モジュール間のDIを避ける
- EventListener で依存モジュールに Event を送る
- @DomainEvent
Bootstrap Modes
- Standalone, Direct dependencies, All dependencies
モジュールのパッケージ直下に配置したクラスは他モジュールに公開される
- サブパッケージ配下のクラスは他モジュールには非公開
相互依存をチェックしてエラーにしてくれる
Documenter
- モジュールの関連グラフを作ってくれる (PlantUML)
Java のモジュールシステムと関係があるものではない
- Moduliths はテストをサポートするもの

2019-06-24

Postman の GraphQL を試してみる

GraphQL

気が付いたら Postman が v7.2 で GraphQL に対応してました。

blog.getpostman.com

まだ Beta 機能のようですが、手元の v7.2.2 で試してみます。とりあえず、GitHub の GraphQL API で。

事前に、GitHub 側で Settings > Developer settings > Personal access tokens > Generate new token からトークンを生成します。とりあえず、スコープは repo あたりをチェック。

で、Headers タブで Authorization: bearer <token> を追加。Body タブで GraphQL をチェックして、https://api.github.com/graphql に POST するとレスポンスが返ります。

f:id:knt_mr:20190624124851p:plain

あと、左ペインの APIs でスキーマを設定できます。

f:id:knt_mr:20190624125250p:plain

ここでは、GitHub の graphql-schema を設定してみます。

github.com

GraphQL の右隣りにあるプルダウンでスキーマを選択すると、GraphiQL のように自動補完ができるようになります。

f:id:knt_mr:20190624130752p:plain

なかなかいい感じ。

2019-06-19

正規表現で含む/含まないを検索する

正規表現

備忘録。

^(?=.*include)(?!.*exclude).*$

現場からは以上です。

2019-06-12

「ふりかえり」をどのようにやるか

雑記

システム開発の現場において設計レビューやコードレビューをすることはよくあるかと思いますが、チームや自分自身の仕事を 継続的に改善する ために取り入れたいことのひとつとして「ふりかえり」があります。

で、ふりかえりのツールとしてよく取り上げられるのが「KPT」です。以前から実践しようと思いつつなかなかできてないのですが、実際に取り組んでみることを想定して方針などをまとめてみようかと。

前提

「今回は○○を試す」など、事前に目標を決める
前回の Try があるなら、それを目標に含める

Keep

試してみてよかったこと
これから続けたいこと

単純に「○○がよかった」だけではなく、なにがよかったのか、どのような効果があったのかを併せて書く。現在形で書くとよさそう。

Problem

試してみてだめだったこと
不満点や問題点
これからリスクになりそうなこと

単純に「○○しなかった」だけではなく、なにがだめだったのか、どんな問題があったのかを併せて書く。あと、あたりまえだけどメンバーを否定するようなことは書かない。

Try

Keep を強化すること
Problem を解決すること

具体的 (定量的) なアクションを書く。次回の KPT で Keep のふりかえりをするために期待する効果を書くとよさそう。

参考記事

kuranuki.sonicgarden.jp

boxil.jp

2019-05-30

BPStudy#141〜DDD(Domain Driven Design)実践の現場に行ってきた #bpstudy

DDD メモ

BPStudy#141〜DDD(Domain Driven Design)実践の現場に行ってきました。簡単に所感をまとめます。

bpstudy.connpass.com

所感

最近、価格計算のロジックを実装する機会があり、個人的にはなかなかホットな内容でした。とはいえ、自分の場合は特にドメイン駆動設計という感じではなかったのですが、価格計算のロジックはアプリケーションのレイヤから分離するようにしました。で、今回の話を聴く限りではこのアプローチ自体はあまり間違いではなかったのかなとなんとなく実感を得られました。

あと、モジュールやメソッドの切り方を考えるときに個人的に意識していることはテストがやりやすいかどうかということ。特に、モックを多用せず、シンプルにテストコードが書けるかどうかは重要かなと思っています。なので、今回の事例として挙げられていた「料金計算ロジックをどうやってコードで表現するか」ということに関して、テストがやりやすいかどうかという観点で考えるのは割とありなのかなと思っている今日この頃です。

料金計算モジュールがどうやったらテストしやすくなるかっていう観点で考えるとよさそうな気がする #bpstudy
— kntmr (@knt_mr) May 29, 2019

そういえば、増田さんの本は読んだことがあるけど、エヴァンスの本は手が出しづらくてまだ読んでない...。そろそろ読んでみるか。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

以下、メモから抜粋。

ドメイン駆動設計の正しい歩き方～どこに焦点をあわせ、どう実践するか

ドメイン駆動設計の正しい歩き方 from 増田亨

www.slideshare.net

ドメイン駆動設計はアーキテクチャや設計に限った話ではない
ソフトウェアの核心にある複雑さに立ち向かう
複雑さはビジネスの複雑さに起因する
- 複雑になる要因はたくさんある
ビジネスルール
- 制約や約束事 (システムやITは関係ない)
ドメインロジック
- ビジネスルールをシステムやソフトウェアとして実現するもの
核心にある複雑さを適切に扱う
- 周辺の複雑さが整理される
- 条件分岐を外に抜き出すと入出力は単純になるはず
  - 分岐が散在するから複雑になる
- 全体の構造が改善する
ドメイン層を独立させる (アーキテクチャの話)
- モデリングのパラダイムと設計/実装のパラダイムを密に結合する
ビジネスの活動を継続的に学ぶ☆
コアドメインに集中することにどれくらい時間を費やせるかがポイント☆
個人ではなくチームの基本方針としてやっているか☆
全体を均質にやるのではなくポイントを絞って深掘りする
- 複雑なものを整理して単純なIFで使えるようにする
ドメイン層に入出力の関心事(画面やテーブル)を持ち込まない
モデルと実装は切り離さない
- 実装のためにモデリングする
- コードをうまく書くにはどのようにモデルを整理すればよいかを意識する
例) 複雑な料金計算ルール
- ドメインロジックを独立させる
- 画面やDBのことを一緒に考えない
モデルで整理してモデルと実装を密に結合する
- ルールを整理する
- モデルで仮説を立ててコードで実現してみる
- コードのリファクタリングとモデルへのフィードバックを繰り返して改善する☆
コアドメインに集中する
- ある軸を選んで簡単なコードを書く、別の軸で簡単なコードを書く☆
- 実験することでモデルの妥当性を検証する
- 中核のルール、周辺のルール、除外すべきルール
ビジネスを深く洞察する
システム間の秩序の改善を続ける
- 連携するシステムや人間を意識する
- どのようにデータを持つべきかがわかってくるはず
ドメイン駆動設計を現場に導入する
- エヴァンス本をちゃんと読む
ドメインエキスパートがちゃんと説明してくれるとは限らない
- 具体例を提示して質問する
- あえて間違っていることを質問して語ってもらうのもあり
- バックオフィスの人の方がルールを知ってるかも (経理のベテランや営業支援スタッフとか)

教材セット

ドメイン駆動設計本格入門 from 増田亨

www.slideshare.net

モデル駆動型開発によるビジネスをソフトウェアに落し込む１つのやり方

モデリング
- モデルを作ることで分かりやすくする
ビジネスとソフトウェアは乖離する
- モデルを中間成果物としてビジネスとソフトウェアを繋げる
モデル駆動型開発(MDA)
- CIM, PIM, PSM, CODE ☆
言語の抽象度は上がっている
- プラットフォームの複雑さから分離する
モデル駆動開発のいいところ☆
言葉を共有
言葉の乖離
- ドメインエキスパート⇔開発者
- 開発者による抽象化は設計の支えにはなるがドメインエキスパートには理解されないかも
ユビキタス言語
- モデルを言語の骨格とする
- コミュニケーションとコードではその言語を用いる
- 用語集とは違う
- 形式知として全体に浸透するもの☆
わからない言葉を整理してビジネスの外観を捉える
言葉を整理する中で気をつけるポイント☆
トランザクションスクリプトになりがち
- 関心事が入出力に寄ることでドメイン層がただの入れ物になる
- テーブル設計から入るとドメインがデータの器になりがち
- ビジネスルールが書かれていない
どこにビジネスルールを書くか
- 育てる

所感

JCP20周年記念セッション

これからのJDK/JVM何を選ぶ？どう選ぶ？

パネルディスカッション: JDKトーク

Meet the Noops

所感

Spring Framework のロードマップと 5.2 の新機能

Spring 5.2 の Kotlin 対応

GraalVMの概要と、Native-Image化によるSpring Boot爆速化の夢

Spring Cloud Netflix

Spring Boot で作るいまどきなモノリス

前提

Keep

Problem

Try

参考記事

所感

ドメイン駆動設計の正しい歩き方～どこに焦点をあわせ、どう実践するか

モデル駆動型開発によるビジネスをソフトウェアに落し込む１つのやり方

パネルディスカッション: JDK トーク