Spring Fest 2018.

1. エンタープライズ・
マイクロサービスの格言
for Beginner
1
妄言

2. 2
⾧谷川 裕一
• 合同会社Starlight&Storm 代表
• 日本Springユーザ会 会⾧
• Springやオブジェクト指向を中心にしたコンサ
ルティングや教育で活動中
https://www.facebook.com/
starlightandstorm/
https://twitter.com/StarlightFuku
2

3. 本日の内容
• はじめに
– 前回のおさらいとか、エンタープライズ・マイクロ
サービスについての妄想
• 企画編
– 要件定義とかチーム編成とか、開発編にうまく入ら
なかった妄想
• 開発編
– エンタープライズ・マイクロサービスを上手くやる
ための妄想
• おわりに
– おわりなき妄想
3

4. はじめに
4

5. 去年の妄言（1/2）
• https://www.slideshare.net/HasegawaDanna1/
spring-fest-
2017?ref=http://springfest2017.springframewo
rk.jp/
5

6. 去年の妄言（2/2）
• オブジェクト指向が分からないのに、マ
イクロサービス（MS）に飛びついてもで
きる訳ない
• そもそも、マイクロにならない
• 方法論もないし、手探りで作れるのか
• SoRには向かない。もし取り組むなら、ハ
イブリッドがいい
6
マイクロサービスでという
開発案件が増えている

7. エンタープライズ・マイクロサービス？
• 主にエンプラ系のシステムを、MSにマイ
グレーションしたシステム
• なんか、普通に定義されているMSとは違
う
– サービスベース・アーキテクチャ(!?)
– 派生開発、レガシ・マイグレーション...とも
かく、ゼロから新規開発ではないようだ
7

8. モチベーション
• エンタープライズ系が得意なSI企業は、マ
イクロサービス・アーキテクチャ
（MSA）でのシステム開発に向かないよ
うだ...
• だけど、MSAでシステム開発したいし、
MSをうまく作りたい
8
色々考えて、破れかぶれになった結果...

9. そうだ！マイクロとは相対的なんだ！
9
クジラのマイクロと、てんとう虫のマイクロは、違う
エンタープライズ・マイクロサービス
エンタープライズ・マイクロサービスの誕生！

10. 企画編
10

11. MSの粒度は勘で決める
• オブジェクト指向が分からなくても、
Java/Springでシステムを作ってきた実績
• 最初の粒度は、業務や機能でMSを分ける
– 必要があれば、徐々に粒度を細かくすれば良い
（その際にDDDができれば尚良し）
11
「単位を気にするな。客観的な尺度ができる
までの間は、主観的な単位を使えばよい」
トム・デマルコ

12. 開発プロセスはアジャイル的である
• 要求とMSA、実装という山を相互に行き
交うことで、谷間を埋めなければ、開発
が上手く進まない
• 探索的な開発である
12
要求要求 MSAMSA 実装実装

13. 適応度関数には品質特性シナリオを使う
• MSでは非機能要件が大事であるにも関わらず、その部
分が抜けて要件定義が終了するケースがある
• 品質特性シナリオを元に非機能要件をMSAに反映させ、
性能テストetcで計測可能とする
13
技術評論社「間違いだらけのソフトウェア・アーキテクチャ」から抜粋

14. クリューバ方式でチームを編成する
• エンタープライズなシステム開発では、技術スキ
ルの低さが問題となるケースがある
• 優秀なチームリーダを配置（育てて配置!?）する
ことで最低限の品質をチームリーダで保障する
14
技術評論社「間違いだらけのソフトウェア・アーキテクチャ」から抜粋

15. 開発編
15

16. 共通処理はやめる
• 処理（業務ロジックや技術要素）を共通化する
ことで、MS個別の進化が損なわれ、コストがか
かる
– 必要があればMSとして切り出す
16
ホテル
予約
列車
予約
ホテル
予約
列車
予約
メール処理 メール

17. 共有静的データはパターン3で！
• 国コードや都道府県コードなどの扱い
17
商品
Service
注文
Service注文
モノリシック
Repository
国コード
TBL
商品 顧客
Repository Repository
顧客
Service
国コード
Service
・パターン1
やり過ぎ、管理などが大変
商品
Service
注文
Service
顧客
Service
・パターン2
不整合も起きやすく、管理などが大変
国コード
RDB
国コード
RDB
国コード
RDB
商品
Servic
e
注文
Servic
e
顧客
Servic
e
・パターン3
多分、最もベターな方法
国コード
.properties
国コード
.properties
国コード
.properties

18. テストはちゃんと作らなければならない
• MSの進化を短時間で行うためにはテストが重要
– CI環境を整える
– カバレッジ率などの品質管理を実施する
18

19. Unitテストは高速化する
• @SpringBootTestを付与してUnitテストを行うと、テスト
の実行時間が掛かり過ぎる
– Spring Boot（APサーバetc）を起動するコスト
– コンポーネントスキャンによる、テストには不要なコンポーネン
トの検索とインスタンス化するコスト
• Unitテストは@RunWith(SpringRunner.class)で行う
– Controller
• @WebMvcTestを利用して、ServiceをMock化する
– Service
• 可能な限りPOJOとしてテストし、依存するクラスはMock化する
– Repository
• @MybatisTestを利用して、 DBUnitのBefore、Afterを使ったテスト
を極力行わない
19

20. 難しいことは避ける
• エンプラ系は複雑なトランザクションを扱うの
で、コレオグラフィとかSagaパターンなど適用
することは困難
• MS間は極力、同期通信でACID確保
– 性能などの問題はインフラで頑張る
20

21. 定説を疑え（1/2）
• 「順番を知る必要がない」は論外で、「複雑に
なる」のでコスト増大!?
21

22. 定説を疑え（2/2）
• レガシはデータがまとまってるなんて、誰が言っ
たの？
– 実はMS化でデータがまとまって、MS間連携が複雑化
22
ホテル
予約
列車
予約
ホテル予約
ユーザ列車予約
ユーザ
ユーザ
管理
ユーザ

23. バッチには注意する
• 「サービス毎にRDBも分けた、依存関係も
片方向に整理した!」としても、バッチが
裏から破壊するかも!?
– バッチによるMSをまたがったServiceオブ
ジェクトやRepositoryオブジェクトの利用
• 結果として、バッチが動かなくなる可能性
が出てくるため、MSを進化させることが
できない
23

24. おわりに
24

25. 「MSじゃないじゃん！」
• そう、だから、
•エンタープライズ・
マイクロサービス
• なんです...。
25

26. 今後について
• エンタープライズ・マイクロサービスを
「できそこないのMS」から「エンタープ
ライズ向けに、MSのいいとこ取りをした
良いモノ」の意味にしたい
• JSUGの勉強会で、事例紹介をお待ちして
ます！
26
「合理的であるな、妥当であれ」
ワインバーグ

27. ご静聴ありがとうございました
27