Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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
ブログ 私が好きなアーキテクチャ (ポートアンドアダプター) を説明する
Slide 33
Slide 33 text
ブログ 腐敗防止層を意識して 綺麗なドメインを保ちたい
Slide 34
Slide 34 text
以降はスキップ設定あり
Slide 35
Slide 35 text
話すこと / 話さないこと ● ● 話すこと 話さないこと
Slide 36
Slide 36 text
対象者 / 非対象者 ● ● 対象者 非対象者
Slide 37
Slide 37 text
登壇を見た人への期待するアクション ● アクション