さいきょうのレイヤードアーキテクチャについて考えてみた

吉祥寺pm 37 での登壇資料です
https://kichijojipm.connpass.com/event/339040/

Transcript

1. さいきょうのレイヤードアーキテクチャ について考えてみた 吉田あひる @吉祥寺.pm37
2. 名前: 吉田あひる (@strtyuu) 仕事: エンジニア 所属: スターフェスティバル株式会社 自己紹介
3. なぜこんな話をしようと思ったのか
4. ビジネスロジックをドメイン層に実装 するって正しいんだっけ？
5. なぜそんな疑問を持ったのか • ドメイン層は大体一番下の層として配置されている • ドメイン層にビジネスロジックを実装するという話はよくきく • でも、ビジネスロジックって普通変わっていくもの ◦ 少なくとも、ビジネスロジックと言われるものの中には安定度の低いものがあるはず • 安定度の低いビジネスロジックがドメイン層に入っているのは影響範囲が広くなりがちであまり嬉しくない んじゃないか？
6. ぼくのかんがえた さいきょうの解決策
7. 変更要求がきたら
8. ドメイン層の手前で吸 収できると理想なの では？
9. どうすればドメイン層の手前で 変更要求を吸収できるか？
10. ノーコードツールが参考になるのでは？ • コードを書かなくとも簡易的なアプリケーションを作成できるすごいやつ
11. ノーコードツールはドメインモデルをいじらない • ノーコードツールを使ってビジネスや業務を回している企業がある • ノーコードツール自身はそれらの企業のビジネスはよく知らない • これはノーコードツールを使ってユーザー自身がビジネスロジックを記述しているような状態 • こうなると、ビジネスロジックに変更があってもドメイン層をいじる必要が全くない
12. なぜノーコードツールは安定しているのか？ • 個別のビジネス的な要件が削ぎ落とされることからドメインモデルの安定性は生まれているのではない か？ • ユーザー自身のドメインモデルの使い方で振る舞いを調整できるからじゃないか？
13. とはいえノーコードツールを目指せばいいわけではない • ノーコードツールは1企業からみると包含する範囲が広すぎる ◦ 抽象度が高すぎて必要な情報の欠落や必要以上の認知負荷上昇につながってしまう • 対象のドメインをちょうど包含できる抽象が良い抽象 ◦ 自社の要求の範囲で抽象化されたドメインモデルを目指していく必要がある
14. ノーコードツールの話をまとめると ... • 個別のビジネス要件をドメインモデルから追い出し抽象化することで安定性が高まる • しかし、何でも抽象化してしまうと抽象度が高くなりすぎて辛い
15. 安定度の低いビジネスロジックだけド メインモデルから追い出せばいいので は？
16. どうやって追い出すのか？
17. 共通性・可変性 • 対象となる物事の中で共通する部分としない部分 • 共通性は静的な構造 ◦ 可変性を受け入れる枠組み • 可変性は動的 • 詳しくはマルチパラダイムデザインという書籍で
18. お弁当で考えてみる • 共通性 ◦ 商品名と価格からなる データ構造 • 可変性 ◦ 具体的な商品名や価格と いった状態
19. PHP で表現してみる • 共通性はクラスという静的な形 で表現 • 可変性は変数として表現
20. PHP で表現できる共通性・可変性（一部） デザインパターンなどは更に様々な共通性・可変性を表現できる ※実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがある 共通性 可変性 機能 振る舞い・データ構造 状態 Class 名前(意味) or 振る舞い 振る舞い or 実装 Interface 振る舞い 型 Trait データ構造 小さい値の組 Enum
21. 要件を可変性で捉えて ビジネスロジックを抽象化してみる
22. 申請アプリケーションの例 • スターフェスティバルはお弁当を販売する ECサイトを運営している • ECサイトに並ぶお弁当は外部の飲食店のものも含まれる • クオリティ担保のため、社内の審査を通過したお弁当だけを ECサイト上に並べている • 商品情報を審査をするためのアプリケーションを構築したい • 「3次審査までできるようにしてほしいです！」
23. 3次審査という要件を 共通性で実装する例 3次審査以外のバリエーションを考慮し ないため、三次承認までのステータス を静的に表現する
24. 3次審査という要件を 可変性で実装する例 2次審査までの申請など承認ステップ のバリエーションを仮定し、動的に表現 したバージョン
25. ドメインモデルに可変性を組み込む • 要件を可変性として捉えることで、ドメインモデルの抽象度が一段上がる • 可変性のスコープ内の変更要求であればドメインモデル自体の変更が不要になる • ドメイン層に変更を加えなくても変更要求に対応できる状態に少し近づいた？
26. YAGNI との付き合い方 • kawashima さんの素晴らしい資料に沿ってやっていくと良さそう ◦ 「それはYAGNIか? それとも思考停止か ?」 https://www.slideshare.net/kawasima/yagni ◦ 変更要求が発生したタイミングなどで変更の発生した部分を可変性に切り出していくといいのではないか • 何でも可変性にしていくと抽象度が高くなりすぎる可能性 • ユースケースの幅が広がりそうなところを可変性にすると面白いことになるかもしれない
27. 可変性についてもっと知りたい人は • マルチパラダイムデザイン • データモデリングでドメインを駆動するという書籍で紹介されている ◦ テーブル駆動方式 ◦ DSL ◦ 定義体方式
28. まとめ • 安定度の低いビジネスロジックをドメイン層に入れると、影響範囲が広くなりがちで辛いのではないか • 安定度を高めるためにはビジネスロジック自体の抽象度を上げていく必要があるのではないか • 要件を可変性で捉えることでドメインモデルの抽象度が上がっていくのではないか • ドメインモデルに可変性を組み込んでいくことで、変更要求をドメイン層の手前で吸収できることが増える のではないか • そうなるとさいきょうのレイヤードアーキテクチャ感があるのではないか
29. We are hiring !!