$30 off During Our Annual Pro Sale. View Details »

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

kirimaru
January 20, 2022

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

kirimaru

January 20, 2022
Tweet

More Decks by kirimaru

Other Decks in Programming

Transcript

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

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

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

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

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

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

  7. そこから派生して…

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

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

  10. 今日のゴール

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

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

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

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

  16. アプリケーションの 「内側」と「外側」の区別をつける • 内側 ◦ アプリケーションのビジネスロジック • 外側 ◦ アプリケーションで完結できない、実行時例外が発生しや

    すいロジック ◦ HTTPを受信するController、DBと接続する Repository、他システムとRESTやSOAPで連携、ファイ ル操作
  17. None
  18. ちょっと脱線

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

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

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

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

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

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

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

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

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

    • アダプターのRepository
  28. 「内側」の知識を「外側」に流出させない :クエリパラメータ • アダプターのController • 内側 • アダプターのRepository こちらは判断が分かれます。 「内側」と言いたいところですが、API仕様書にデフォルト値で補

    完する旨を書いているのであれば、そのロジックは「外側」の持ち 物なのでアダプターのControllerで行っても良いでしょう
  29. 終わりに アーキテクチャに正解はありません。 しかし、同一の理解をしておくことで、どこにロジックを入れるべきかを話し合う ことができます。 心理的安全性を確保して、知的コンバットでより良くしていきたいですね。

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

  31. Appendix

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

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

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

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

  36. 対象者 / 非対象者 • • 対象者 非対象者

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