私が好きなポートアンドアダプターを紹介する/I-like-hexagonal-architecture.pdf

イベント：https://rakus.connpass.com/event/233514/

ブログ：https://nainaistar.hatenablog.com/
Twitter：https://twitter.com/nainaistar

Transcript

1. 私が好きなアーキテクチャ
   (ポートアンドアダプター)
   を紹介する
   設計 モデリング LT会 - vol.3　#modelinglt
   きり丸（水上　皓登）@nainaistar
   

   View Slide

2. 名前：きり丸（水上 皓登）
   twitter：nainaistar
   GitHub：hirotoKirimaru
   ブログ：きり丸の技術日記
   https://nainaistar.hatenablog.com/
   2
   アーキテクチャを
   考えるのは
   非常に楽しい
   

   View Slide

3. エンジニアの仕事は
   概念に名前を付けること
   

   View Slide

4. 特化していれば
   特化しているほど良い
   

   View Slide

5. ただし、
   他システムから得られるモデルは
   他システムのモデル
   

   View Slide

6. 他システムモデルは流用せずに
   自分のモデルに変換しよう
   

   View Slide

7. そこから派生して…
   

   View Slide

8. システム連携間に限らず
   アプリの内部と外部と意識すると
   良い設計になるのでは？
   

   View Slide

9. それを意識したアーキテクチャが
   ポートアンドアダプター
   

   View Slide

10. 今日のゴール
    

    View Slide

11. アーキテクチャの
    ポートアンドアダプター
    を知って「内側」と「外側」
    の概念を知って実践する
    

    View Slide

12. ポートアンドアダプター
    （ヘキサゴナルアーキテクチャ）
    

    View Slide

13. View Slide

14. 私がアーキテクチャで意識していること
    ● アプリケーションの「内側」と「外側」の区別をつける
    ● 「外側」の知識を「内側」に侵入させない
    ● 「内側」の知識を「外側」に流出させない
    

    View Slide

15. アプリケーションの
    「内側」と「外側」の
    区別をつける
    

    View Slide

16. アプリケーションの
    「内側」と「外側」の区別をつける
    ● 内側
    ○ アプリケーションのビジネスロジック
    ● 外側
    ○ アプリケーションで完結できない、実行時例外が発生しや
    すいロジック
    ○ HTTPを受信するController、DBと接続する
    Repository、他システムとRESTやSOAPで連携、ファイ
    ル操作
    

    View Slide

17. View Slide

18. ちょっと脱線
    

    View Slide

19. ガチのFIzzBuzz
    1から100までの数をプリントするプログラムを書け。
    ただし3の倍数のときは数の代わりに｢Fizz｣と、
    5の倍数のときは｢Buzz｣と、
    3と5両方の倍数の場合には｢FizzBuzz｣と
    プリントすること。
    

    View Slide

20. ガチのFIzzBuzz 緑：内部 赤：外部
    1から100までの数をプリントするプログラムを書け。
    ただし3の倍数のときは数の代わりに｢Fizz｣と、
    5の倍数のときは｢Buzz｣と、
    3と5両方の倍数の場合には｢FizzBuzz｣と
    プリントすること。
    

    View Slide

21. 「外側」の知識を
    「内側」に侵入させない
    

    View Slide

22. 「外側」の知識を「内側」に侵入させない
    例えば：
    Aシステムでは運転免許証を「001」と定義していて、
    Bシステムでは運転免許証を「AAA」と定義している。
    => ドメインで001とAAAは運転免許証として扱う？
    => 「外側」から「内側」には翻訳してから扱う。
    ・Aシステムの値は001をBに翻訳する
    ・Bシステムの値はAAAをBに翻訳する
    

    View Slide

23. 「外側」の知識を「内側」に侵入させない
    腐敗防止層という仕組み
    でガードしやすくなる
    

    View Slide

24. 「内側」の知識を
    「外側」に流出させない
    

    View Slide

25. 「内側」の知識を「外側」に流出させない
    ：メールシステム
    メールを送るシステムにデータ連携をする場合、
    メールのデータ作成ロジックは
    どこに持つべきでしょうか。
    ● 内側
    ● アダプターのメールシステム
    

    View Slide

26. 「内側」の知識を「外側」に流出させない
    ：メールシステム
    ● 内側
    ● アダプターのメールシステム
    「内側」で作成するべきです。
    メール文面、誰に送るかといった情報は
    「外側」に流出させるべきではありません。「内側」でデータを作
    成し、「外側」は「内側」から受け取ったデータをメールシステムに
    連携できるように加工すると良いでしょう。
    

    View Slide

27. 「内側」の知識を「外側」に流出させない
    ：クエリパラメータ
    特定のクエリパラメータが存在しないとき、デフォルト値で検索す
    るシステムがあったとします。
    その場合、デフォルト値で補完するロジックは次のどこに入れる
    べきでしょうか。
    ● アダプターのController
    ● 内側
    ● アダプターのRepository
    

    View Slide

28. 「内側」の知識を「外側」に流出させない
    ：クエリパラメータ
    ● アダプターのController
    ● 内側
    ● アダプターのRepository
    こちらは判断が分かれます。
    「内側」と言いたいところですが、API仕様書にデフォルト値で補
    完する旨を書いているのであれば、そのロジックは「外側」の持ち
    物なのでアダプターのControllerで行っても良いでしょう
    

    View Slide

29. 終わりに
    アーキテクチャに正解はありません。
    しかし、同一の理解をしておくことで、どこにロジックを入れるべきかを話し合う
    ことができます。
    心理的安全性を確保して、知的コンバットでより良くしていきたいですね。
    

    View Slide

30. 「内側」と「外側」を意識した
    ポートアンドアダプターを考えると
    ロジックの存在するべき箇所が
    見えやすくなってくるので
    いかがでしょうか
    

    View Slide

31. Appendix
    

    View Slide

32. ブログ
    私が好きなアーキテクチャ
    (ポートアンドアダプター)
    を説明する
    

    View Slide

33. ブログ
    腐敗防止層を意識して
    綺麗なドメインを保ちたい
    

    View Slide

34. 以降はスキップ設定あり
    

    View Slide

35. 話すこと / 話さないこと
    ● ●
    話すこと 話さないこと
    

    View Slide

36. 対象者 / 非対象者
    ● ●
    対象者 非対象者
    

    View Slide

37. 登壇を見た人への期待するアクション
    ●
    アクション
    

    View Slide