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

by kirimaru

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

そこから派生して…

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

今日のゴール

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

ちょっと脱線

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Appendix

Slide 32

Slide 32 text

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