Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス

JSUG 2015 Spring in Summer ~ 夏なのにSpring 菊池陽一

菊池陽一 Github: yo1000 hatena: Yoichi-KIKUCHI

Spring 歴: 5年 2007.04中堅 SIer 新卒入社 2009.12社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring 適用を模索

みなさん

Spring どんなふうに使っていますか？

• 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト






なんにでも適用できますよね (とくにバックエンドシステムでは)

非常に多機能かつ柔軟に設計されている

Spring ならでは

Java をメインにシステム構築しているのであれば

Spring を選ばない手はない

むしろ

Spring に非ずんば Java に非ず

現在それくらい採用の広がっている実感があります

たとえば Atlassian

Confluence ではランタイムオブジェクトの管理に Spring を使用している

たとえば JetBrains

TeamCity では独自拡張した Spring コンテナを使用している

たとえば JetBrains

サードパーティ製フルスタックフレームワークで IntelliJ のデフォルトサポートがあるのは Spring のみ！

現在国外のみならず国内でも広く認知され採用に至っている

そんな Spring ですが実際の業務適用についてはというと...

いままさに仕掛中！とかこれからやりたい！とか

そこでこれまでの 5年すこしで感じた Spring についてのあれこれをご紹介

株式会社リクルートライフスタイル菊池陽一


2007.04中堅 SIer 新卒入社 2009.12社内標準フレームワーク開発Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring の適用を模索

2007.11Spring Framework 2.5



2013.12 Spring Framework 4.0

略歴






略歴

バッドノウハウ収集期






略歴

ベタープラクティス実践期

バッドノウハウ収集期当時そんなつもりは全くありませんでしたが振り返ってみるとバッドノウハウが多かった...

社内標準フレームワーク開発● Spring Framework 3.0 GA ベース

● MVC フレームワークには Wicket を採用

● サービスレイヤ以下を自社開発 • ビジネスプロセスをテンプレートパターンにより実装

• bean 定義でサービス同士を相互に呼び出せるような仕組みを作りこんでいた





Good!





Good!

Bad!!





Good!

Bad!!

Bad!!

何が良くなかったのか

一般的な Spring Project

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

Request

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

Request

社内標準としていたフレームワーク

InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access

Business Requirements

InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access


MVC フレームワークを Wicket に固定していた

Wicket

Controller

View

InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access



Wicket

Controller

View

Bad!!

InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access



Wicket

Controller

View

Bad!!

進化し続けるフロント技術やこれに伴う要件に応えるためせめて View は柔軟に変更可能であるべき

Better

事実として View を取りまくフレームワークは変化し続けている

Servlet + JSP Struts + JSP Struts + Velocity Struts2 + FreeMaker Spring MVC + FreeMaker Spring MVC + Thymeleaf

バッドノウハウ.1• 適用する MVC Framework を制限してしまった

• 制限して、同じものを繰り返し使わせることで確実にナレッジは蓄積しやすくなるが、要件に応えられないのであれば意味は無い

• あるべき姿は柔軟に選択可能な状態 • そのうえで選択肢となりうるフレームワークの特徴やメリット/デメリット/ナレッジなどが事前に展開されているとより良い

InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access


InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access


Service レイヤ以降の本来の構成を無視してテンプレートパターンを適用

InHouse

Service DB Access


InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access



InHouse

Service DB Access


Bad!!

InHouse

Service

Spring Framework

Aspect J

Wicket

Controller

View DB Access



InHouse

Service DB Access


Bad!!

コンポーネントごとの DI を意識した上で適切に責務分割を行い疎な状態を維持する Better

適切な責務分割とは？

Spring には都合の良いことに各種コンポーネントアノテーションが用意されている

@Controller @Service @Repository @Component @Configuration etc...

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

@Controller

@Service

@Repository

@Component

@Configuration

これに倣うだけで適切に責務は分割される

本当に適切？基準は？

テストがしやすいか

バッドノウハウ.2• DI を無視して適切な責務分割を行っていなかった

• テンプレートパターンは有用なデザインパターンのひとつだが、どんな規模でも有効に作用するとは限らない

• 適切な責務分割を意識する • Spring の場合、都合の良いことに、責務を各種コンポーネントアノテーションで定義しておりこれに倣うだけで適切な分割が働く


● MVC フレームワークには Struts2 を採用

● サービスレイヤ以下を自社開発 • テンプレートパターンによる実装 • bean 定義でサービス同士を相互に呼び出せるような仕組みを実装

第2弾


● MVC フレームワークには Struts2 を採用

● サービスレイヤ以下を自社開発 • テンプレートパターンによる実装 • bean 定義でサービス同士を相互に呼び出せるような仕組みを実装

Good!

Bad!!

Bad!!

第2弾

良くなかったポイントはほぼ同じ

なので割愛

その後

転職して新たな環境へと移り...

実はしばらくの間Spring を適用する

機会に恵まれなかった

そんな中目にしてきたものは

オレオレフレームワーク

リクルートでの開発事情● ニジボックス (2012-2013)

• カードエンジンと呼ばれるソシャゲ開発用のプロジェクトテンプレートが用意されていた

• PHP によるオレオレフレームワーク

● リクルートライフスタイル (2013-) • R2 と呼ばれる Seasar2 + SAStruts ベースのオレオレフレームワーク

• 前職で作ってきたものと同じ臭いを感じた






Bad!!






Bad!!

Bad!!

中途入社したわたしは非常に苦労しました

オレオレフレームワークに

ありがちな多くの事象が現場で発生していた

整備不足のドキュメント

(ネットで引いてももちろん見つからない)

フレームワークに縛られるインフラ

(セキュリティリスクに対するコスト増を招く)

使用可能な技術が限定的

(新たな技術を取り入れるにはトンチが必要)

フレームワークのクセを把握していることが

仕事になる (クセというか不具合というか...)

なんでこんなことすらできないの！？？

Spring なら30分で解決するのに...!

そんなものにあふれていた

こう思うに至る

　オレオレ

フレームワーク　

ダメ｡ゼッタイ｡

やめましょう

バッドノウハウ収集期　　　　　　まとめ

● Spring を使用する上で、周辺アーキテクチャに縛りを加えてはいけない

● Spring のレイヤデザイン (Controller/Service/Repository/Template) を無視してはいけない

● 作り方に制限が加わるような独自の作り込みをおこなってはいけない





過度な独自仕様の作りこみやオレオレフレームワークの開発を行ってはいけない








略歴






略歴

ベタープラクティス実践期

ベタープラクティス実践記

ベタープラクティス実践記

ベタープラクティス実践記？

ベタープラクティス実践記エンドレスに改善しつづけたいので

あえて「ベスト」という言葉は使用していません

これまで集めたバッドノウハウをもとにより良い

使い方を考えてみる

集まったバッドノウハウたち● Spring を使用する上で、周辺アーキテクチャに縛りを加えてはいけない






Spring を使用する上で、周辺アーキテクチャに縛りを加えてはいけない


どうするべきか



>> Spring では、HTML や JSP などの他、レスポンス可能なあらゆるものをController が返却できることを意識する


より具体的には...



>> Spring MVC を採用し、さまざまな Viewへ対応可能にしておく。RestController を使用してフロントを完全分離する (バックエンドシステムの API 化を促進する)


@Controller @RequestMapping("employees")public class EmployeeController { @RequestMapping(produces = "text/html") public String getHtml() { return "employee"; } @RequestMapping(produces = "application/json", consumes = ..) @ResponseBody public String getJson() { return new Employee("Yoichi", "RLS", 30); }

@RequestMapping(produces = "application/xml", consumes = ..) @ResponseBody public String getXml() { return new Employee("Yoichi", "RLS", 30); } }




扱うデータは同じ




扱うデータは同じ

表現の方法が異なる







>> Spring では、RDB の他、スキーマレスDB、ファイル、API、などあらゆる外部リソースを永続化レイヤで扱うことを意識する



>> Spring MVC を採用し、さまざまな Viewへ対応可能にしておく。RestControllerを使用してフロントを完全分離する (バックエンドシステムの API 化を促進する)



>> Spring MVC を採用し、さまざまな Viewへ対応可能にしておく。RestControllerを使用してフロントを完全分離する (バックエンドシステムの API 化を促進する)

>> Repository レイヤを抽象化してどのような外部リソースへも切替可能にしておく


public interface EmployeeRepository { Employee getItem();}

@Repository @Primary public class EmployeeJdbcRepository implements EmployeeRepos.. {}＠Repository public class EmployeeMongoRepository implements EmployeeRep.. {}

@Service public class EmployeeService { @Autowired public EmployeeService(EmployeeRepository employeeRepository) {} }





Serviceが見るのは interface





Serviceが見るのは interface

Primary 側が DI される＠Bean + @ConditionalOn 等の利用でより柔軟に




Spring のレイヤデザイン (Controller/Service/Repository/Template) を無視してはいけない





>> Spring のレイヤデザインに従い、適切に責務分割を行うことを意識して、各レイヤが疎な状態を維持できるように注意して設計・実装を行う





>> @Controller → URL と View、Service の紐付けを表現




>> @Service → 業務プロセスを表現




>> @Service → 業務プロセスを表現

>> @Repository → 外部リソースアクセスを表現

Controller

Service

Repository

Template

Spring Framework

Aspect J

View

@Controller

@Service

@Repository

@Component

@Configuration




作り方に制限が加わるような独自の作り込みをおこなってはいけない





>> Spring をなるべくそのまま使いましょうこれに限ります





>> Spring をベースにライブラリを追加していく形で製品を作り上げる



>> Spring をベースにライブラリを追加していく形で製品を作り上げる

>> 独自の作りこみを行う場合は、コア機能に影響を与えないよう着脱可能な実装を意識する(プラグイン/アドオンのようなイメージで)

@Aspect @Component public class ResponseWrapperAdvice { @Around("execution(* com.yo1000.controller.*.*(..)) && " + "@annotation(..annotation.RequestMapping)") public Object appendPrefix(ProceedingJoinPoint joinPoint) throws .. { Object ret = joinPoint.proceed(); if (ret instanceof Employee) { Employee emp = (Employee) ret; emp.setName(emp.isMale() ? ("Mr. " + emp.getName()) : "Ms. " + emp.getName()); } return ret; } }




AOP を使用



AOP を使用

指定したメソッドパターン、アノテーションパターンの処理に割り込む

ベタープラクティス実践記　　　　　　まとめ

● Spring MVC を使用した上で Microservices のような設計を意識してシステム間依存をなるべく疎な状態に保つ (API 化、Repository の抽象化)

● Spring のレイヤデザイン (Controller/Service/Repository/Template) に従った実装を意識する

● 独自の作り込みが発生する場合は、プラグイン的な実装を心がける (Bad: 継承/Better: AOP)


● Spring MVC を使用した上で Microservices のような設計を意識してシステム間依存をなるべく疎な状態に保つ (Repository の抽象化)

● Spring のレイヤデザイン (Controller/Service/Repository/Template) をに従う


SpringFramework の理解を深めましょう


おわりに





過度な独自仕様の作りこみやオレオレフレームワークの開発を行ってはいけない


● Spring MVC を使用した上で Microservices のような設計を意識してシステム間依存をなるべく疎な状態に保つ (Repository の抽象化)

● Spring のレイヤデザイン (Controller/Service/Repository/Template) をに従う


SpringFramework の理解を深めましょう

おわりに

最終的な着地としては、わりと一般的なお話になってしまいました。ですが、Springは進化を続けています。今回お話した内容もいつ覆るかはわかりません。

わたしも5年前にSpringに触れ始めた頃には、現在のSpringBootのような非常に簡単かつパワフルな機能が出てくるとは思ってもいませんでした。そういう意味でも、わたし自身もSpringの進化を引き続き追いかけて行きたいと思います！

Appendix

vis• KPI VISualizer • システムに、時間と値の二軸表現可能な結果を返す SQL を登録することで、これを動的にグラフ化して表示してくれるもの。

• Spring Boot を使用したプロジェクト。 • https://github.com/yo1000/vis

https://github.com/yo1000/vis

bluefairy• Docker Web Client • Docker Remote API をプロパティに設定して起動すると、Docker イメージの閲覧や、コンテナの起動が行える Web Client。

• Spring Boot を使用したプロジェクト。 • https://github.com/yo1000/bluefairy

https://github.com/yo1000/bluefairy

dbspock• spock ライクに DBUnit を使用できるようにしたライブラリ

• Groovy を使用したプロジェクト。 • https://github.com/yo1000/dbspock

https://github.com/yo1000/dbspock

<dependencies> <dependency> <groupId>com.yo1000</groupId> <artifactId>dbspock</artifactId> <version>0.1.2.RELEASE</version> </dependency> </dependencies> <repositories> <repository> <id>com.yo1000</id> <name>yo1000 maven repository</name> <url>http://yo1000.github.io/maven/</url> </repository> </repositories>

dbspock

class RepositorySpec extends Specification {

def "DBSpockTest"() {

setup:

def tester = new DataSourceDatabaseTester(dataSource)

def data = {

_cols_ 'SHOP_ID' | 'SHOP_NAME' | 'SHOP_CREATED'

shop 'SP-1' | 'BURGER KING' | '2015-04-01'

shop 'SP-2' | 'RANDYS DONUTS' | '2015-04-01'

}

def flatxml = {

data.call()

data.build()

}

data.delegate = new SpockLikeFlatXmlBuilder()

tester.dataSet = new FlatXmlDataSet(new StringReader(flatxml.call()))

tester.onSetup()

expect:

...

dbspock

Technology

Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス