MV*
MVCやMVVMなど色々な概念がある。
MVC
- MVCモデルとは 役割ごとにModel, View, Controllerに分割してコーディングを行うモデル
Webアプリケーションサーバの役割
- データベースや全文検索エンジンといったミドルウェアからデータを取得、更新する
- ページを構築する
- HTTPのインターフェースとしてユーザからの入力情報を得る など
従来のWebアプリケーション
従来のWebアプリケーションは、HTMLを基本とし、動きもシンプルでした。とくにCGIをメインとしていたときは主にHTMLだけで構成され、JavaScriptは多少インタラクティブなことをする程度のアプリケーションが多かったのです。この時代のWebアプリケーションサーバはモノリシックな1枚のサーバで作られていることが多く、データベースとのやりとりからHTMLの構築までを1つのアプリケーションとして構築していました。
2000年代になると、JavaScriptでHTTPリクエストを行う、「Ajax通信」という概念が浸透し、徐々にWebアプリケーションはリッチでインタラクティブになっていきます。リッチなWebアプリケーションが増えてクライアントに処理が集中してくると、サーバ側はAPIでデータのみを送受信することが増えてきました。
さらに、Webアプリケーションだけではなく、モバイルアプリケーションなどクライアントのバリエーションが増えてくると、サーバはさらに1つのことに集中した形に特化したAPIを構築することになります。「マイクロサービス」と呼ばれるように「特定のリソースを扱うことに特化したアーキテクチャ」として進化するようになりました。
しかし、クライアントが多様化してくるとすべてのクライアントの要求に応えるAPIサーバを作るのが難しくなります。モ バイルアプリケーションとWebアプリケーションを作るとしても同じUIにはなりません。またクライアントごとにそれぞれ要求される項目が異なる場合があります。たとえばWebアプリケーションを作った場合でも、PCとスマートフォンでは画面の大きさの違いからユーザーが見える情報が異なっていたり、モバイルアプリケーションとは全く異なるUIとなったりすることもあります。
さらにWebアプリケーションは、HTTP/1.1において同時にリクエストできる数が6つまでに制約されているなどの環境的な制限もあります。
これらの状況を鑑みて、フロントエンド側にクライアントごとの要求に応えるためのサーバを配置してバックエンドのAPIサーバとの橋渡し役とするアーキテクチャが開発されるようになりました。BFFによってHTMLを構築したり、リクエストの数を少なくしたりできるなどの利点があるからです。
このようにして「BFF」と呼ばれるアーキテクチャが作られるようになりました。
BFFの続きは参考URLの続きにある。
BFFはフロントエンジニア、バックエンドエンジニアのどちらが担当するのか
BFFは、クライアント側を担当するフロ ントエンドエンジニアが開発を担当することが多いです。BFFはサーバであるため、バックエンドエンジニアが開発すると思われることもありますが、UIを構築、操作する手助けをするサーバであるため、フロントエンドエンジニアの担当領域になります。
BFFアーキテクチャでは、バックエンドエンジニアはAPIを基本として、リソースを管理するのが担当領域になります。
アプリケーション・アーキテクチャ
アプリケーション・アーキテクチャについて学ぶとMVCや3層アーキテクチャといった言葉にたどりつく
- 2種類の3層
伝統的なWebアプリケーションは以下のように3種類のサーバから成り立つ このサーバ構成を3層アーキテクチャということがある。
一方、アプリケーションサーバで動いているプログラムの内部構造も以下のように3層に分離することがある。 ※これも3層アーキテクチャということがある。
アプリケーション・アーキテクチャの基本は3層
Webアプリケーションなどのプログラムの構成を考えるとき、一番基本になるのは以下の3層に分割すること
- プレゼンテーション層(またはユーザーインターフェース層)
- ビジネスロジック層(またはアプリケーション層)
- データアクセス層
プレゼンテーション層 ユーザーとやりとりするのがプレゼンテーション層
ビジネスロジック層 グーがチョキに勝ち、チョキがパーに勝ち、パーにグーが勝つなどのルールを持つのがビジネスロジック層
データアクセス層 ジャンケンの結果を保存するのであればデータアクセス層の仕事
CLI アプリだろうが Web アプリだろうが、それはプレゼンテーション層が異なるだけです。 また、データの保存先がファイルだろうが DB だろうが、それはデータアクセス層が異なるだけです。
「表示上の関心と、コアなルールと、データの永続化を分離する」という 3 層が何より基本です。
MVCと3層の関係
MVCと3層アーキテクチャの関係を図にすると以下となる。
MVCは3層アーキテクチャと比較するとプレゼンテーション層周辺に着目している
MVCとは
MVC（Model View Controller モデル・ビュー・コントローラ）は、ユーザーインタフェースをもつアプリケーションソフトウェアを実装するためのデザインパターンである。
実は、MVC、MVP、MVVM といったものは、すべてプレゼンテーション層のアーキテクチャなのです。
なので、アプリケーションの構成を検討するときに、「MVC にするぜ」というだけでなく、「全体としては 3 層で、プレゼンテーション層は MVC にする」という話になるわけです。 ちなみに、上図から明らかだと思いますが、MVC で言う Model 1は、ただのデータの入れ物ではありません。Model はビジネスロジックを書くところです。 「グーがチョキに勝ち、チョキがパーに勝ち、パーがグーに勝つ」と言ったコアなルール (ビジネスロジック) を View や Controller には書いてはいけません
ビジネスロジック層
ビジネスロジック層には大きく次の2種類の実装方法がある。
- トランザクションスクリプト
- ドメインモデル
-
トランザクションスクリプト いわゆる手続き型プログラミングを使って実装する方式 データとgetter,setterだけを持つようなDTOといった入れ物とサービスクラスを作成しサービスに処理を書くのが定番 Javaだな
-
ドメインモデル データを持つクラスに処理も書くという、オブジェクト指 向プログラミングで実装する方式 草なぎさんと話していたやつか
ここで言うオブジェクト指向とは？
オブジェクト指向プログラミングと手続き型プログラミングでは、データと処理が一緒にいるかどうかが大きく異なる
ドメインモデル方式では、オブジェクト指向で実装するため、「データ」を内部に隠蔽したオブジェクトに対し「処理」を命令するようなコードになります。
Java などのオブジェクト指向言語を使っていて、DTO を new していても、それはオブジェクト指向ではありません。 DTO にデータだけを持たせて処理はサービスに記述するのではなく、データと処理を同じクラスに書くのがオブジェクト指向プログラミングであり、ドメインモデルという実装方式です。
ドメインモデル方式はトランザクションスクリプトと比較して、学習コストや初期実装コストが高い代わりに、長期的に変更に強いアプリケーションになるとされています。
ドメインモデルの場合は4層になることも
ドメインモデルの実装例は、DDD という手法の中でもまとめられています。 多くの例では、ビジネスロジック層を「アプリケーション層」と「ドメイン層」の 2 つに分離しています
ドメイン層は、「グーがチョキに勝つ、チョキがパーに勝つ、パーがグーに勝つ」といったコアなロジックを持つ層であり、ピュアなオブジェクト指向モデルの世界として実装されます。 これがいわゆる「オブジェクト指向により現実世界をプログラムに反映する」というやつです。2
これに対して、アプリケーション層は以下のような役割を担います。
- ドメイン層のオブジェクトたち (ドメインモデル) に対する操作でユースケース(活用事例)を実現する
- ピュアなオブジェクト指向モデルの世界に入れたくない、トランザクション管理のような、アプリケーション都合のロジックを実現する
データアクセス層
データアクセス層はDBなどにデータを保存する責務を持つ層ですが、O/Rマッパーに任せて、一切コードを書かない場合があります。
- コントローラー : ハンドラーともいうことがある。 Webアプリケーションにおけるコントローラーには、このほかにWebに関する一般的な仕事を受け持つという側面がある。 例として、セッション管理やURLの解釈、HTTPリクエスト・レスポンスの処理・クッキーの管理などを担当する。