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

Slide 1

Slide 1 text

さいきょうのレイヤードアーキテクチャについて考えてみた吉田あひる @吉祥寺.pm37

Slide 2

Slide 2 text

名前: 吉田あひる (@strtyuu) 仕事: エンジニア所属: スターフェスティバル株式会社自己紹介

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

とはいえノーコードツールを目指せばいいわけではない ● ノーコードツールは1企業からみると包含する範囲が広すぎる ○ 抽象度が高すぎて必要な情報の欠落や必要以上の認知負荷上昇につながってしまう ● 対象のドメインをちょうど包含できる抽象が良い抽象 ○ 自社の要求の範囲で抽象化されたドメインモデルを目指していく必要がある

Slide 14

Slide 14 text

ノーコードツールの話をまとめると ... ● 個別のビジネス要件をドメインモデルから追い出し抽象化することで安定性が高まる ● しかし、何でも抽象化してしまうと抽象度が高くなりすぎて辛い

Slide 15

Slide 15 text

安定度の低いビジネスロジックだけドメインモデルから追い出せばいいのでは？

Slide 16

Slide 16 text

どうやって追い出すのか？

Slide 17

Slide 17 text

共通性・可変性 ● 対象となる物事の中で共通する部分としない部分 ● 共通性は静的な構造 ○ 可変性を受け入れる枠組み ● 可変性は動的 ● 詳しくはマルチパラダイムデザインという書籍で

Slide 18

Slide 18 text

お弁当で考えてみる ● 共通性 ○ 商品名と価格からなるデータ構造 ● 可変性 ○ 具体的な商品名や価格といった状態

Slide 19

Slide 19 text

PHP で表現してみる ● 共通性はクラスという静的な形で表現 ● 可変性は変数として表現

Slide 20

Slide 20 text

PHP で表現できる共通性・可変性（一部）デザインパターンなどは更に様々な共通性・可変性を表現できる ※実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがある共通性可変性機能振る舞い・データ構造状態 Class 名前(意味) or 振る舞い振る舞い or 実装 Interface 振る舞い型 Trait データ構造小さい値の組 Enum

Slide 21

Slide 21 text

要件を可変性で捉えてビジネスロジックを抽象化してみる

Slide 22

Slide 22 text

申請アプリケーションの例 ● スターフェスティバルはお弁当を販売する ECサイトを運営している ● ECサイトに並ぶお弁当は外部の飲食店のものも含まれる ● クオリティ担保のため、社内の審査を通過したお弁当だけを ECサイト上に並べている ● 商品情報を審査をするためのアプリケーションを構築したい ● 「3次審査までできるようにしてほしいです！」

Slide 23

Slide 23 text

3次審査という要件を共通性で実装する例 3次審査以外のバリエーションを考慮しないため、三次承認までのステータスを静的に表現する

Slide 24

Slide 24 text

3次審査という要件を可変性で実装する例 2次審査までの申請など承認ステップのバリエーションを仮定し、動的に表現したバージョン

Slide 25

Slide 25 text

ドメインモデルに可変性を組み込む ● 要件を可変性として捉えることで、ドメインモデルの抽象度が一段上がる ● 可変性のスコープ内の変更要求であればドメインモデル自体の変更が不要になる ● ドメイン層に変更を加えなくても変更要求に対応できる状態に少し近づいた？

Slide 26

Slide 26 text

YAGNI との付き合い方 ● kawashima さんの素晴らしい資料に沿ってやっていくと良さそう ○ 「それはYAGNIか? それとも思考停止か ?」 https://www.slideshare.net/kawasima/yagni ○ 変更要求が発生したタイミングなどで変更の発生した部分を可変性に切り出していくといいのではないか ● 何でも可変性にしていくと抽象度が高くなりすぎる可能性 ● ユースケースの幅が広がりそうなところを可変性にすると面白いことになるかもしれない

Slide 27

Slide 27 text

可変性についてもっと知りたい人は ● マルチパラダイムデザイン ● データモデリングでドメインを駆動するという書籍で紹介されている ○ テーブル駆動方式 ○ DSL ○ 定義体方式

Slide 28

Slide 28 text

まとめ ● 安定度の低いビジネスロジックをドメイン層に入れると、影響範囲が広くなりがちで辛いのではないか ● 安定度を高めるためにはビジネスロジック自体の抽象度を上げていく必要があるのではないか ● 要件を可変性で捉えることでドメインモデルの抽象度が上がっていくのではないか ● ドメインモデルに可変性を組み込んでいくことで、変更要求をドメイン層の手前で吸収できることが増えるのではないか ● そうなるとさいきょうのレイヤードアーキテクチャ感があるのではないか

Slide 29

Slide 29 text

We are hiring !!