More Related Content
What's hot (20)
Similar to Jsug2015 summer spring適用におけるハ?ット?ノウハウとヘ?ターフ?ラクティス (20)
Recently uploaded (11)
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 appendPre?x(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 appendPre?x(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 appendPre?x(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