Recommended
More Related Content
What's hot
What's hot (20)
Similar to Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス
Similar to Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス (20)
Recently uploaded
Recently uploaded (16)
Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス
- 1. JSUG 2015 Spring in Summer 夏なのにSpring 菊池 陽一
- 2. 菊池 陽一 Github: yo1000 hatena: Yoichi-KIKUCHI Spring 歴: 5年 2007.04 中堅 SIer 新卒入社 2009.12 社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring 適用を模索
- 3. みなさん
- 5. • 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト
- 6. • 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト
- 7. • 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト
- 8. • 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト
- 9. • 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト
- 10. • 社内標準 • 受託案件 • 自社プロダクト • ベンダプロダクト • 日曜プロダクト
- 15. むしろ
- 19. たとえば JetBrains TeamCity では 独自拡張した Spring コンテナを使用している
- 27. 2007.04 中堅 SIer 新卒入社 2009.12 社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring の適用を模索 2007.11 Spring Framework 2.5 2009.12 Spring Framework 3.0 2011.12 Spring Framework 3.1 2013.12 Spring Framework 4.0 略歴
- 28. 2007.04 中堅 SIer 新卒入社 2009.12 社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring の適用を模索 2007.11 Spring Framework 2.5 2009.12 Spring Framework 3.0 2011.12 Spring Framework 3.1 2013.12 Spring Framework 4.0 略歴 バッドノウハウ収集期
- 29. 2007.04 中堅 SIer 新卒入社 2009.12 社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring の適用を模索 2007.11 Spring Framework 2.5 2009.12 Spring Framework 3.0 2011.12 Spring Framework 3.1 2013.12 Spring Framework 4.0 略歴 ベタープラクティス実践期
- 31. 社内標準フレームワーク開発 ● Spring Framework 3.0 GA ベース ● MVC フレームワークには Wicket を採用 ● サービスレイヤ以下を自社開発 • ビジネスプロセスをテンプレートパターン により実装 • bean 定義でサービス同士を相互に呼び出せるよ うな仕組みを作りこんでいた
- 32. 社内標準フレームワーク開発 ● Spring Framework 3.0 GA ベース ● MVC フレームワークには Wicket を採用 ● サービスレイヤ以下を自社開発 • ビジネスプロセスをテンプレートパターン により実装 • bean 定義でサービス同士を相互に呼び出せるよ うな仕組みを作りこんでいた Good!
- 33. 社内標準フレームワーク開発 ● Spring Framework 3.0 GA ベース ● MVC フレームワークには Wicket を採用 ● サービスレイヤ以下を自社開発 • ビジネスプロセスをテンプレートパターン により実装 • bean 定義でサービス同士を相互に呼び出せるよ うな仕組みを作りこんでいた Good! Bad!!
- 34. 社内標準フレームワーク開発 ● Spring Framework 3.0 GA ベース ● MVC フレームワークには Wicket を採用 ● サービスレイヤ以下を自社開発 • ビジネスプロセスをテンプレートパターン により実装 • bean 定義でサービス同士を相互に呼び出せるよ うな仕組みを作りこんでいた Good! Bad!! Bad!!
- 35. 何が良くなかったのか
- 44. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements
- 45. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements MVC フレームワークを Wicket に固定していた Wicket Controller View
- 46. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements MVC フレームワークを Wicket に固定していた Wicket Controller View Bad!!
- 47. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements MVC フレームワークを Wicket に固定していた Wicket Controller View Bad!! 進化し続けるフロント技術や これに伴う要件に応えるため せめて View は柔軟に 変更可能であるべき Better
- 49. Servlet + JSP Struts + JSP Struts + Velocity Struts2 + FreeMaker Spring MVC + FreeMaker Spring MVC + Thymeleaf
- 50. バッドノウハウ.1 • 適用する MVC Framework を制限してしまった • 制限して、同じものを繰り返し使わせることで 確実にナレッジは蓄積しやすくなるが、 要件に応えられないのであれば意味は無い • あるべき姿は柔軟に選択可能な状態 • そのうえで選択肢となりうるフレームワークの 特徴やメリット/デメリット/ナレッジなどが 事前に展開されているとより良い
- 51. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements
- 52. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements Service レイヤ以降の本来の構成を無視して テンプレートパターンを適用 InHouse Service DB Access Business Requirements
- 53. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements Service レイヤ以降の本来の構成を無視して テンプレートパターンを適用 InHouse Service DB Access Business Requirements Bad!!
- 54. InHouse Service Spring Framework Aspect J Wicket Controller View DB Access Business Requirements Service レイヤ以降の本来の構成を無視して テンプレートパターンを適用 InHouse Service DB Access Business Requirements Bad!! コンポーネントごとの DI を意識した上で 適切に責務分割を行い 疎な状態を維持する Better
- 55. 適切な責務分割とは？
- 60. 本当に適切？ 基準は？
- 61. テストがしやすいか
- 62. バッドノウハウ.2 • DI を無視して適切な責務分割を行っていなかった • テンプレートパターンは有用な デザインパターンのひとつだが、 どんな規模でも有効に作用するとは限らない • 適切な責務分割を意識する • Spring の場合、都合の良いことに、責務を 各種コンポーネントアノテーションで 定義しておりこれに倣うだけで適切な分割が働く
- 63. 社内標準フレームワーク開発 ● Spring Framework 3.1 GA ベース ● MVC フレームワークには Struts2 を採用 ● サービスレイヤ以下を自社開発 • テンプレートパターンによる実装 • bean 定義でサービス同士を相互に呼び出せるよ うな仕組みを実装 第2弾
- 64. 社内標準フレームワーク開発 ● Spring Framework 3.1 GA ベース ● MVC フレームワークには Struts2 を採用 ● サービスレイヤ以下を自社開発 • テンプレートパターンによる実装 • bean 定義でサービス同士を相互に呼び出せるよ うな仕組みを実装 Good! Bad!! Bad!! 第2弾
- 66. その後
- 69. そんな中 目にしてきたものは
- 70. オレオレ フレームワーク
- 71. リクルートでの開発事情 ● ニジボックス (2012-2013) • カードエンジンと呼ばれるソシャゲ開発用の プロジェクトテンプレートが用意されていた • PHP によるオレオレフレームワーク ● リクルートライフスタイル (2013-) • R2 と呼ばれる Seasar2 + SAStruts ベースの オレオレフレームワーク • 前職で作ってきたものと同じ臭いを感じた
- 72. リクルートでの開発事情 ● ニジボックス (2012-2013) • カードエンジンと呼ばれるソシャゲ開発用の プロジェクトテンプレートが用意されていた • PHP によるオレオレフレームワーク ● リクルートライフスタイル (2013-) • R2 と呼ばれる Seasar2 + SAStruts ベースの オレオレフレームワーク • 前職で作ってきたものと同じ臭いを感じた Bad!!
- 73. リクルートでの開発事情 ● ニジボックス (2012-2013) • カードエンジンと呼ばれるソシャゲ開発用の プロジェクトテンプレートが用意されていた • PHP によるオレオレフレームワーク ● リクルートライフスタイル (2013-) • R2 と呼ばれる Seasar2 + SAStruts ベースの オレオレフレームワーク • 前職で作ってきたものと同じ臭いを感じた Bad!! Bad!!
- 82. そんなものに あふれていた
- 83. こう 思うに至る
- 85. やめましょう
- 86. バッドノウハウ収集期 まとめ ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない
- 87. バッドノウハウ収集期 まとめ ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない 過度な独自仕様の作りこみや オレオレフレームワーク の開発を行ってはいけない
- 90. 2007.04 中堅 SIer 新卒入社 2009.12 社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring の適用を模索 2007.11 Spring Framework 2.5 2009.12 Spring Framework 3.0 2011.12 Spring Framework 3.1 2013.12 Spring Framework 4.0 略歴
- 91. 2007.04 中堅 SIer 新卒入社 2009.12 社内標準フレームワーク開発 Spring Framework との出会い 2011.04 社内標準フレームワーク更新 2012.08 リクルート入社 (ニジボックス) 2013.07 リクルートライフスタイル転籍 MARQREL、HOTPEPPER で Spring の適用を模索 2007.11 Spring Framework 2.5 2009.12 Spring Framework 3.0 2011.12 Spring Framework 3.1 2013.12 Spring Framework 4.0 略歴 ベタープラクティス実践期
- 92. ベタープラクティス実践記
- 93. ベタープラクティス実践記
- 94. ベタープラクティス実践記 ？
- 97. 集まったバッドノウハウたち ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない
- 98. 集まったバッドノウハウたち ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない
- 101. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない どうするべきか >> Spring では、HTML や JSP などの他、 レスポンス可能なあらゆるものを Controller が返却できることを意識する
- 103. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない より具体的には... >> Spring MVC を採用し、さまざまな View へ対応可能にしておく。RestController を使用してフロントを完全分離する (バック エンドシステムの API 化を促進する)
- 104. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない @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); } }
- 105. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない @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); } } 扱うデータは同じ
- 106. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない @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); } } 扱うデータは同じ 表現の方法が異なる
- 107. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない どうするべきか >> Spring では、HTML や JSP などの他、 レスポンス可能なあらゆるものを Controller が返却できることを意識する
- 108. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない どうするべきか >> Spring では、HTML や JSP などの他、 レスポンス可能なあらゆるものを Controller が返却できることを意識する >> Spring では、RDB の他、スキーマレス DB、ファイル、API、などあらゆる外部リ ソースを永続化レイヤで扱うことを意識する
- 109. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない より具体的には... >> Spring MVC を採用し、さまざまな View へ対応可能にしておく。RestController を使用してフロントを完全分離する (バック エンドシステムの API 化を促進する)
- 110. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない より具体的には... >> Spring MVC を採用し、さまざまな View へ対応可能にしておく。RestController を使用してフロントを完全分離する (バック エンドシステムの API 化を促進する) >> Repository レイヤを抽象化してどのよう な外部リソースへも切替可能にしておく
- 111. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない 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) {} }
- 112. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない 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
- 113. Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない 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 Primary 側が DI される ＠Bean + @ConditionalOn 等の利用でより柔軟に
- 114. 集まったバッドノウハウたち ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない
- 115. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない
- 116. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない どうするべきか
- 117. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない どうするべきか >> Spring のレイヤデザインに従い、 適切に責務分割を行うことを意識して、 各レイヤが疎な状態を維持できるように 注意して設計・実装を行う
- 118. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない より具体的には...
- 119. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない より具体的には... >> @Controller → URL と View、Service の紐付けを表現
- 120. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない より具体的には... >> @Controller → URL と View、Service の紐付けを表現 >> @Service → 業務プロセスを表現
- 121. Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない より具体的には... >> @Controller → URL と View、Service の紐付けを表現 >> @Service → 業務プロセスを表現 >> @Repository → 外部リソースアクセスを表現
- 123. 集まったバッドノウハウたち ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない
- 129. 作り方に制限が加わるような 独自の作り込みをおこなってはいけない より具体的には... >> Spring をベースにライブラリを 追加していく形で製品を作り上げる >> 独自の作りこみを行う場合は、 コア機能に影響を与えないよう 着脱可能な実装を意識する (プラグイン/アドオンのようなイメージで)
- 130. @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; } } 作り方に制限が加わるような 独自の作り込みをおこなってはいけない
- 131. @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 を使用
- 132. @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 を使用 指定したメソッドパターン、 アノテーションパターンの処理に割り込む
- 133. ベタープラクティス実践記 まとめ ● Spring MVC を使用した上で Microservices のよ うな設計を意識してシステム間依存をなるべく疎な 状態に保つ (API 化、Repository の抽象化) ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) に従った実装を意識する ● 独自の作り込みが発生する場合は、プラグイン的な 実装を心がける (Bad: 継承/Better: AOP)
- 134. ベタープラクティス実践記 まとめ ● Spring MVC を使用した上で Microservices のよ うな設計を意識してシステム間依存をなるべく疎な 状態に保つ (Repository の抽象化) ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) をに従う ● 独自の作り込みが発生する場合は、プラグイン的な 実装を心がける (Bad: 継承/Better: AOP) SpringFramework の理解を深めましょう
- 136. おわりに
- 137. バッドノウハウ収集期 まとめ ● Spring を使用する上で、 周辺アーキテクチャに縛りを加えてはいけない ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) を無視してはいけない ● 作り方に制限が加わるような 独自の作り込みをおこなってはいけない 過度な独自仕様の作りこみや オレオレフレームワーク の開発を行ってはいけない
- 138. ベタープラクティス実践記 まとめ ● Spring MVC を使用した上で Microservices のよ うな設計を意識してシステム間依存をなるべく疎な 状態に保つ (Repository の抽象化) ● Spring のレイヤデザイン (Controller/Service/ Repository/Template) をに従う ● 独自の作り込みが発生する場合は、プラグイン的な 実装を心がける (Bad: 継承/Better: AOP) SpringFramework の理解を深めましょう
- 139. おわりに
- 141. Appendix
- 142. vis • KPI VISualizer • システムに、時間と値の二軸表現可能な結果を返す SQL を登録することで、これを動的にグラフ化し て表示してくれるもの。 • Spring Boot を使用したプロジェクト。 • https://github.com/yo1000/vis
- 144. bluefairy • Docker Web Client • Docker Remote API をプロパティに設定して起動 すると、Docker イメージの閲覧や、コンテナの起 動が行える Web Client。 • Spring Boot を使用したプロジェクト。 • https://github.com/yo1000/bluefairy
- 146. dbspock • spock ライクに DBUnit を使用できるようにした ライブラリ • Groovy を使用したプロジェクト。 • https://github.com/yo1000/dbspock
- 148. 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