速攻使え!! ソフトウェアアーキテクチャ的発想 | 木下博貴 | @kinocoboy2 | baboblog | https://baboblog.com/ | https://twitter.com/kinocoboy2

1. Peacock #01
速攻使え!! ソフトウェアアーキテクチャ的発想

2. Self Introduction
Hiroki.Kinoshita
Peacock Engineer Group ( PEG )
Organizer
株式会社KUNO
深層学習とCloudを駆使するDX推進企業
Front Engineer / Designer
Twitter: @kinocoboy2
Blog: Baboblog

3. Peacock Engineer Group の紹介

4. Peacock Engineer Group
• PEG の 目的
• 地域や会社・社会人・学生などの垣根を越えて、
自由に楽しく技術力を高め合えるコミュニティ
に!!
• PEG が取り扱うテーマ
• 「明日から使えるTips」
• 運営スタッフ随時募集中!

5. イベントの楽しみ方
• Twitter とSpecialChat を駆使
• #PEACOCK
• どんどん呟いていきましょー
• 質問は、Twitter でもいいし、SpecialChat の
チャット欄からでもOKです。
• オンラインなので積極的にやってみましょー
• 懇親会も有志で行います。
• SpecialChat の 広場で行います。
• 色々交流しましょー

6. 速攻使え!!
ソフトウェアアーキテクチャ的発想

7. PMBOK 第七版

8. PMBOKの改定
PMBOK(ピンボック)とは、
世界中のプロマネの実務家から意見を集めてプロジェクトマネジメン
トについて知識体系化している分厚い本。
最近、結構業界がざわつく変化が!!

9. 「成果物の提供」から「価値の提供」へ

10. 「成果物の提供」から「価値の提供」へ
世界的に案件進行は、ウォーターフォール型開発からアジャイル開発
へのピボットが行われた様子。
さらに、「価値を提供する」ためには「価値を見出さなければならな
い」という難しさも発生してきた。

11. 価値を見出すための方法
そのために、DDD(ドメイン駆動設計) や モデリング・ユーザーストー
リーマッピングなどの要件を抽象化して整理する手法が一気に普及し
ている。
しかし、この手法は覚えればすぐに順応できるかと言うとNOだ。

12. 価値提供型の進め方や価値の探索には、試行錯誤しながらユーザーヒ
アリングを繰り返す必要がある。
そのスピードが速く、従来のウォーターフォール型に慣れている場
合、ピボット（大胆に捨てて・また生かして）が難しい。
なぜすぐ順応できないのか

13. 大胆な開発を行えるようになるために、以下手法が有効になる
- 部分的な安全性を常に担保し続けるテスト駆動設計
- 役割を明確にして進めるイベント駆動設計・クリーンアーキテクチャ
これを始めるためには、責任範囲の分解ノウハウがいる。
大胆に捨てたり・生かしたりするために

14. 逆に

15. テスト駆動設計・イベント駆動設計・クリーンアーキテクチャの入り
口に立つことができる。
そしてこれらを利用できるようになってくると、DDDやモデリングな
どの素早いピボットが要求される設計手法でも柔軟に対応できるよう
になってくる。
今回は、責任範囲の分解に注力していきたいと思う。
責任範囲の分解ができるようになれば

16. 例題
• 責任範囲の分解を知らず
• 動くものだけを目指したのでテストも実際に動か
してみたりする感じ
• 確かに動くが…
• 全て main に詰め込んでいるので、どこかでトラ
ブルが起きたら main 全体を debug しなけれ
ば…
• Main の テストって結局何をチェックすれば…
とあるヒヨコード🐥

17. ヒヨコードの責任分解には、DI(Dependency Injection)の考え方が使え
そうだ。
DIとは、「依存オブジェクトを注入」と呼ばれるデザインパターンの
事。
これを使ってヒヨコードをバラしていこう
責任分解には

18. 例題
• まず一番ごちゃついているdatabase 疎通周りから。
• Main を動かすとき、database instance まで立ち
上げてからquery を発行する仕組みになってい
る。
• まずは query の部品の責任範囲を外してみる。
• Query を実行するためには、 database instance
と query param があれば分解できるので、
model という領域を作ってDBとやりとりをさせ
た。
• これによって、DB周りでトラブルが起きた
ら、model だけを見れば良くなった
とあるヒヨコード🐥

19. 例題
• 次にmain を起動するたびに毎回 database instance
up している部分をやめよう。
• Main を動かすために、 model が必要であり、
model は database instance を欲しがるなら、
main にも database instance を外から与えてあげ
れば良い。
• この対応で、database instance は システムで単
一である形が約束される。これはsingleton という
デザインパターン。
• Main のテストをするとき、 database instance と
query parameter を入れたら動作確認が取れるよ
うになった。
とあるヒヨコード🐥

20. 例題
• 次にbusiness logic をmain から分離しよう。
• これの分離には、 query の result があればlogic
は回せそうだ。
• Main 関数ではなく、 logic function として考え
る。
• Logic を分離させることで、 main の動作確認
で必要なことは param parse と param
validate のみ残されている。
• Logic は model result があれば、単体でテス
トできるからだ。
とあるヒヨコード🐥

21. ① 責任分解には、DI化が有効。
② DIは「依存オブジェクト注入」というデザインパターン。
③ 依存オブジェクトを入れるためには、in, out を整理しよう。
④ システムで単一であることを守りたいなら、singleton というデザ
インパターンは有効
⑤ この知見は、モダンな設計を進めるための基礎である。
まとめ

22. ご静聴ありがとうございました
ソフトウェアアーキテクチャ「的」発想

23. 質疑応答