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

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

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

なぜこんな話をしようと思ったのか

ビジネスロジックをドメイン層に実装するって正しいんだっけ？

なぜそんな疑問を持ったのか • ドメイン層は大体一番下の層として配置されている • ドメイン層にビジネスロジックを実装するという話はよくきく • でも、ビジネスロジックって普通変わっていくもの ◦ 少なくとも、ビジネスロジックと言われるものの中には安定度の低いものがあるはず •
安定度の低いビジネスロジックがドメイン層に入っているのは影響範囲が広くなりがちであまり嬉しくないんじゃないか？

ぼくのかんがえたさいきょうの解決策

変更要求がきたら

ドメイン層の手前で吸収できると理想なのでは？

どうすればドメイン層の手前で変更要求を吸収できるか？

ノーコードツールが参考になるのでは？ • コードを書かなくとも簡易的なアプリケーションを作成できるすごいやつ

ノーコードツールはドメインモデルをいじらない • ノーコードツールを使ってビジネスや業務を回している企業がある • ノーコードツール自身はそれらの企業のビジネスはよく知らない • これはノーコードツールを使ってユーザー自身がビジネスロジックを記述しているような状態 • こうなると、ビジネスロジックに変更があってもドメイン層をいじる必要が全くない

なぜノーコードツールは安定しているのか？ • 個別のビジネス的な要件が削ぎ落とされることからドメインモデルの安定性は生まれているのではないか？ • ユーザー自身のドメインモデルの使い方で振る舞いを調整できるからじゃないか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are hiring !!

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

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

y_ahiru

More Decks by y_ahiru

Other Decks in Programming

Featured

Transcript