Webアプリのアーキテクチャの歴史と進化

Webアプリのアーキテクチャの歴史と進化
 アリエルネットワークCTO 
 井上誠一郎


自己紹介+宣伝
 書籍
「P2P教科書」
「パーフェクトJava」
「サーバサイドJavaScript入門」
「パーフェクトJavaScript」


今回の講義
- Webアプリのアーキテクチャの俯瞰
- 基軸がないと散漫になるのでPoEAAを開始点
- 専門用語は[用語]ページで整理
 

参考図書
- PoEAA マーチン・ファウラー
  http://martinfowler.com/eaaCatalog/index.html
- J2EE ロッド・ジョンソン


変わらない目的
- 理解しやすい設計/コード
- 変更に強い設計/コード


パラダイムシフト(1)
- 名著や偉い人の言葉でも、その時代なりの制約の下にある
- 制約が変われば常識も変わる


パラダイムシフト(2)
- Xは正しい...
 - オブジェクト指向は正しい...
 - MVCアーキテクチャは正しい...
 =&gt; 危険な物言い


パラダイムシフト(3)
- Xは今わかっている範囲では
  - 理解しやすい設計/コード
  - 変更に強い設計/コード
  の目的を達成しやすい技法としてXがある、
  と考えるべき
 

パラダイムシフト(4)
- マーケティングメッセージには裏がある
- 会社が落ち目になると、あっさり否定される


書籍「PoEAA」(1)
- エンタープライズアプリに関するアーキテクチャのパターン集
- 原題: Patterns of Enterprise Application Architecture
- http://martinfowler.com/eaaCatalog/index.html


書籍「PoEAA」(2)
- この時代のJ2EEの建前はWeb限定ではないが
- PoEAAは事実上Webアプリ限定
- 言外にアンチEJBを漂わせる本(ロッド・ジョンソンと共通)


書籍「Core J2EE Patterns」
- EJB前提
- 「Core J2EE Patterns」
- http://www.corej2eepatterns.com/


J2EE(Java EE5より前)の前提
- ネイティブのGUIアプリの常識が支配
- Web以外のフロントエンドも考慮
- WebコンテナとEJBコンテナの分離
- Webにステートフルの世界を持ち込むのが進歩だった(cf. REST)


エンタープライズアプリとは
- 元は、J2EEのマーケティングメッセージ
- 大規模コード
- 大規模ユーザ(スケーラビリティを考慮)
- 業務アプリ


エンタープライズアプリ「悪魔の辞典」
- 平凡な業務アプリ開発者に、自分たちは何かすごいことをしているのだと思わせるための用語


まじめに言い直すと
- 今現在、エンタープライズアプリを他と特に区別する必要はない
- ただし、過剰な分割や過剰な抽象化に注意
 - cf. KISSの原則(Keep it simple, stupid)
 - cf. YAGNI(You ain't gonna need it)
 - cf. セカンドシステム症候群


パターンの意義
- 名前をつけること
- 同じ形式(フォーマット)を使うこと


PoEAAの構成要素
- 3層(3 tier)アーキテクチャ
 - プレゼンテーション層
 - ドメイン層
 - データソース層


プログラミングの黄金律(1)
- 関心の分離(separation of concerns)
- 設計とは「どう分割するかの決定」


[用語] tierとlayer
- 3 tierは元々、J2EEのマーケティングメッセージ(悪魔の辞典「ハードをたくさん売るための...」)
- 日本語ではどちらも層
- 違いはそれほど明確ではない
 - tier: 物理的な区分
 - layer: 論理的な区分
 - 出典: PoEAA


J2EE(Java EE5より前)の3 tierに対応する規格
- プレゼンテーション層 =&gt; Webサーブレット
- ドメイン層 =&gt; EJB(セッションBean)
- データソース層 =&gt; EJB(エンティティBean)


Java EE(5以降)の3 tierに対応する規格
- プレゼンテーション層 =&gt; Webサーブレット/JSF/CDI
- ドメイン層 =&gt; CDI/EJB
- データソース層 =&gt; JPA


Java EEの変遷
- J2EE時代の過剰な分割(サーブレットコンテナ/EJBコンテナ)
- 過剰な分割への反動
- Java EEのCDI(DIコンテナ化)
- 後ほど再考察


PoEAAのプレゼンテーション層
- プレゼンテーション層とはWeb層のこと
  (MVCのVの同義と誤解されやすい。今となっては誤解と糾弾する必要もない)
- Web層はMVCアーキテクチャがデファクト標準


MVCアーキテクチャの要点
- 役割の分割
- 依存関係の整理
- 以下の制約は必須
 - ModelはViewに依存してはいけない
 - ViewはModelに依存してよい


プログラミングの黄金律(2)
- 適切な分割は適切な制約の下に宿る
 - 依存
 - ネーミング
 - スコープ


MVCアーキテクチャの変遷
- MVC2から開始(今、MVC2と呼ぶ人は少数派)
- MVCフレームワーク全盛


モデルの多義性(流派の違い)
- ドメインロジック層
- 単なるDTO(Spring Frameworkパターン)
- データソース層と一体化(アクティブレコードパターン)


PoEAAのMVC
<a href="/wp/wp-content/uploads/2012/03/mvc1.png"><img src="/wp/wp-content/uploads/2012/03/mvc1-150x150.png" alt="" title="mvc1" width="150" height="150" class="aligncenter size-thumbnail wp-image-1520" /></a>


Spring FrameworkのMVC
<a href="/wp/wp-content/uploads/2012/03/mvc2.png"><img src="/wp/wp-content/uploads/2012/03/mvc2-150x150.png" alt="" title="mvc2" width="150" height="150" class="aligncenter size-thumbnail wp-image-1521" /></a>


PoEAAのコントローラパターン
- ページコントローラパターン
- フロントコントローラパターン


コントローラの変遷
- MVCフレームの多くは事実上フロントコントローラパターン
- フレームワークの使い手から見ると、ページとフロントでの区別が意味をなくしている
- REST化でURLルーティング(URLを内部ロジックから分離すべき論から、URLこそAPIの世界観へパラダイムシフト)


コントローラの役割の整理
- モデルとビューの制御(狭義のコントローラ)
- URLルーティング(ディスパッチ処理)
- データバインディング(HTTPの世界と内部のデータ変換)


PoEAAのビューパターン
- テンプレート
- トランスフォーム(XSLT)


ビューの変遷
- テンプレート言語がデファクト標準
- XLSTは(ほぼ)死んだ
- Java EE6のJSF(JSPからFaceletsへ)
- GUI風ウィジェット(WicketやZKなど)
- クライアントサイドにビューコードを移動(HTML5時代の動向)


PoEAAのドメイン層のパターン
- ドメインモデル
- トランザクションスクリプト
- テーブルモジュール


PoEAAのデータソース層のパターン
- アクティブレコード
- データマッパー
- クエリオブジェクト(SQLビルダ)


[用語] ビジネス/ドメイン
- ほぼ同義
- ビジネス &lt;=&gt; システムで対比される用語
 - システムの例: Web/RDBMS/OS
- アプリ &lt;=&gt; ドメインで対比される用語
 - アプリの例: Web層(プレゼンテーション)


[用語] データベースまわり
- データソース
- リソース
- パーシステント
- EIS(Enterprise Information System)


[用語] データベースアクセスまわり
- エンティティ(EJBのエンティティBean)
- データマッパー
- データアクセス(DAO)


分割と疎結合
- 進化すると
- 部品をつなぐコードに複雑さが移行する
 =&gt; パターンの発達


プログラミングの黄金律(3)
- Butler Lampsonの格言
- 「Any problem in computer science can be solved with another level of indirection」
- 「計算機科学のあらゆる問題は別のレベルの間接参照で解決される」


部品をつなぐコードの役割の分類
- 探す(+生成する)
- 接続する(+データ変換)
- 交換データ


[用語] サービスを探す/オブジェクトを生成するパターン
- レポジトリ
- レジストリ
- ブローカ
- ロケータ
- ディスパッチャ
- ルータ
- [JNDI]


[用語] 接続する/データ変換するパターン
- ファサード
- サービス
- デレゲート
- ゲートウェイ
- アダプタ
- アクセス


[用語] 交換データのパターン
- DTO(Data Transfer Object)
- VO(Value Object)


疎結合コードのパターンは分散コードに似る
- 探す: URL, directory, search engine, UDDI
- 接続: HTTP, URL, WSDL
- 交換データ: XML, JSON, フォームデータ


部品をつなぐパターン
- フレームワーク化


サーブレットコンテナ
<a href="/wp/wp-content/uploads/2012/03/fw1.png"><img src="/wp/wp-content/uploads/2012/03/fw1-150x150.png" alt="" title="fw1" width="150" height="150" class="aligncenter size-thumbnail wp-image-1516" /></a>


J2EE
<a href="/wp/wp-content/uploads/2012/03/fw2.png"><img src="/wp/wp-content/uploads/2012/03/fw2-150x150.png" alt="" title="fw2" width="150" height="150" class="aligncenter size-thumbnail wp-image-1517" /></a>


過剰な分割への反動
- Webとドメインの分割への反動 =&gt; RESTフレームワーク
- データソースとドメインの分割への反動 =&gt; ActiveRecord
- 合わせ技 =&gt; HTTPメソッドからDBのCRUD操作を直つなぎ


MVCフレームワーク
<a href="/wp/wp-content/uploads/2012/03/fw3.png"><img src="/wp/wp-content/uploads/2012/03/fw3-150x150.png" alt="" title="fw3" width="150" height="150" class="aligncenter size-thumbnail wp-image-1518" /></a>


DI(Dependency Injection)
- ファクトリ(オブジェクト作成の役割を分割)
- コンテナ(オブジェクトのライフサイクル管理の役割を分割)
- 必要なオブジェクトを宣言的に記述すると、DIコンテナが必要なオブジェクトを生成(かつライフサイクル管理もお任せ)してセットしてくれる


DIコンテナ
<a href="/wp/wp-content/uploads/2012/03/fw4.png"><img src="/wp/wp-content/uploads/2012/03/fw4-150x150.png" alt="" title="fw4" width="150" height="150" class="aligncenter size-thumbnail wp-image-1519" /></a>

DIの副次的効果
- 目的のメソッドに引数を渡すために呼び出し途中のメソッドに不要な引数を追加するアンチパターン
- 目的のメソッドやオブジェクトにDIする


まとめ
- Webアプリのアーキテクチャの歴史の変遷を話しました
- 分割は設計の要ですが過剰な抽象化には注意しましょう
- パターンはフレームワーク化しましょう
- 世間一般で流布するパターンは部品をつなぐコードに偏りがちです
- なぜなら偉い人が見る/語る世界は必ずしも問題固有領域ではないからです
- 問題固有領域のパターンの発見は現場の人の仕事です

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

Webアプリのアーキテクチャの歴史と進化

アリエルネットワークCTO

井上誠一郎

自己紹介+宣伝

書籍

「P2P教科書」

「パーフェクトJava」

「サーバサイドJavaScript入門」

「パーフェクトJavaScript」

今回の講義

- Webアプリのアーキテクチャの俯瞰

- 基軸がないと散漫になるのでPoEAAを開始点

- 専門用語は[用語]ページで整理

参考図書

- PoEAA マーチン・ファウラー

http://martinfowler.com/eaaCatalog/index.html

- J2EE ロッド・ジョンソン

変わらない目的

- 理解しやすい設計/コード

- 変更に強い設計/コード

パラダイムシフト(1)

- 名著や偉い人の言葉でも、その時代なりの制約の下にある

- 制約が変われば常識も変わる

パラダイムシフト(2)

- Xは正しい...

- オブジェクト指向は正しい...

- MVCアーキテクチャは正しい...

=> 危険な物言い

パラダイムシフト(3)

- Xは今わかっている範囲では

- 理解しやすい設計/コード

- 変更に強い設計/コード

の目的を達成しやすい技法としてXがある、

と考えるべき

パラダイムシフト(4)

- マーケティングメッセージには裏がある

- 会社が落ち目になると、あっさり否定される

書籍「PoEAA」(1)

- エンタープライズアプリに関するアーキテクチャのパターン集

- 原題: Patterns of Enterprise Application Architecture

- http://martinfowler.com/eaaCatalog/index.html

書籍「PoEAA」(2)

- この時代のJ2EEの建前はWeb限定ではないが

- PoEAAは事実上Webアプリ限定

- 言外にアンチEJBを漂わせる本(ロッド・ジョンソンと共通)

書籍「Core J2EE Patterns」

- EJB前提

- 「Core J2EE Patterns」

- http://www.corej2eepatterns.com/

J2EE(Java EE5より前)の前提

- ネイティブのGUIアプリの常識が支配

- Web以外のフロントエンドも考慮

- WebコンテナとEJBコンテナの分離

- Webにステートフルの世界を持ち込むのが進歩だった(cf. REST)

エンタープライズアプリとは

- 元は、J2EEのマーケティングメッセージ

- 大規模コード

- 大規模ユーザ(スケーラビリティを考慮)

- 業務アプリ

エンタープライズアプリ「悪魔の辞典」

- 平凡な業務アプリ開発者に、自分たちは何かすごいことをしているのだと思わせるための用語

まじめに言い直すと

- 今現在、エンタープライズアプリを他と特に区別する必要はない

- ただし、過剰な分割や過剰な抽象化に注意

- cf. KISSの原則(Keep it simple, stupid)

- cf. YAGNI(You ain't gonna need it)

- cf. セカンドシステム症候群

パターンの意義

- 名前をつけること

- 同じ形式(フォーマット)を使うこと

PoEAAの構成要素

- 3層(3 tier)アーキテクチャ

- プレゼンテーション層

- ドメイン層

- データソース層

プログラミングの黄金律(1)

- 関心の分離(separation of concerns)

- 設計とは「どう分割するかの決定」

[用語] tierとlayer

- 3 tierは元々、J2EEのマーケティングメッセージ(悪魔の辞典「ハードをたくさん売るための...」)

- 日本語ではどちらも層

- 違いはそれほど明確ではない

- tier: 物理的な区分

- layer: 論理的な区分

- 出典: PoEAA

J2EE(Java EE5より前)の3 tierに対応する規格

- プレゼンテーション層 => Webサーブレット

- ドメイン層 => EJB(セッションBean)

- データソース層 => EJB(エンティティBean)

Java EE(5以降)の3 tierに対応する規格

- プレゼンテーション層 => Webサーブレット/JSF/CDI

- ドメイン層 => CDI/EJB

- データソース層 => JPA

Java EEの変遷

- J2EE時代の過剰な分割(サーブレットコンテナ/EJBコンテナ)

- 過剰な分割への反動

- Java EEのCDI(DIコンテナ化)

- 後ほど再考察

PoEAAのプレゼンテーション層

- プレゼンテーション層とはWeb層のこと

(MVCのVの同義と誤解されやすい。今となっては誤解と糾弾する必要もない)

- Web層はMVCアーキテクチャがデファクト標準

MVCアーキテクチャの要点

- 役割の分割

- 依存関係の整理

- 以下の制約は必須

- ModelはViewに依存してはいけない

- ViewはModelに依存してよい

プログラミングの黄金律(2)

- 適切な分割は適切な制約の下に宿る

- 依存

- ネーミング

- スコープ

MVCアーキテクチャの変遷

- MVC2から開始(今、MVC2と呼ぶ人は少数派)

- MVCフレームワーク全盛

モデルの多義性(流派の違い)

- ドメインロジック層

- 単なるDTO(Spring Frameworkパターン)

- データソース層と一体化(アクティブレコードパターン)

PoEAAのMVC

Spring FrameworkのMVC

PoEAAのコントローラパターン

- ページコントローラパターン

- フロントコントローラパターン

コントローラの変遷

- MVCフレームの多くは事実上フロントコントローラパターン

- フレームワークの使い手から見ると、ページとフロントでの区別が意味をなくしている

- REST化でURLルーティング(URLを内部ロジックから分離すべき論から、URLこそAPIの世界観へパラダイムシフト)

コントローラの役割の整理

- モデルとビューの制御(狭義のコントローラ)

- URLルーティング(ディスパッチ処理)

- データバインディング(HTTPの世界と内部のデータ変換)

PoEAAのビューパターン

- テンプレート

- トランスフォーム(XSLT)

ビューの変遷

- テンプレート言語がデファクト標準

- XLSTは(ほぼ)死んだ

- Java EE6のJSF(JSPからFaceletsへ)

- GUI風ウィジェット(WicketやZKなど)

- クライアントサイドにビューコードを移動(HTML5時代の動向)

PoEAAのドメイン層のパターン

- ドメインモデル

- トランザクションスクリプト

- テーブルモジュール

PoEAAのデータソース層のパターン

- アクティブレコード

- データマッパー

- クエリオブジェクト(SQLビルダ)

[用語] ビジネス/ドメイン

- ほぼ同義

- ビジネス <=> システムで対比される用語

- システムの例: Web/RDBMS/OS

- アプリ <=> ドメインで対比される用語

- アプリの例: Web層(プレゼンテーション)

[用語] データベースまわり

- データソース

- リソース

- パーシステント

- EIS(Enterprise Information System)

[用語] データベースアクセスまわり

- エンティティ(EJBのエンティティBean)

- データマッパー

- データアクセス(DAO)

分割と疎結合

- 進化すると

- 部品をつなぐコードに複雑さが移行する

=> パターンの発達

プログラミングの黄金律(3)

- Butler Lampsonの格言

- 「Any problem in computer science can be solved with another level of indirection」

- 「計算機科学のあらゆる問題は別のレベルの間接参照で解決される」

部品をつなぐコードの役割の分類

- 探す(+生成する)

- 接続する(+データ変換)

- 交換データ

[用語] サービスを探す/オブジェクトを生成するパターン

- レポジトリ

- レジストリ

- ブローカ

- ロケータ

- ディスパッチャ

- ルータ

- [JNDI]

[用語] 接続する/データ変換するパターン

- ファサード

- サービス

- デレゲート

- ゲートウェイ

- アダプタ

- アクセス

[用語] 交換データのパターン

- DTO(Data Transfer Object)

- VO(Value Object)

疎結合コードのパターンは分散コードに似る

- 探す: URL, directory, search engine, UDDI

- 接続: HTTP, URL, WSDL

- 交換データ: XML, JSON, フォームデータ

部品をつなぐパターン

- フレームワーク化

サーブレットコンテナ

J2EE

過剰な分割への反動

- Webとドメインの分割への反動 => RESTフレームワーク

- データソースとドメインの分割への反動 => ActiveRecord

- 合わせ技 => HTTPメソッドからDBのCRUD操作を直つなぎ

MVCフレームワーク

DI(Dependency Injection)

- ファクトリ(オブジェクト作成の役割を分割)

- コンテナ(オブジェクトのライフサイクル管理の役割を分割)

- 必要なオブジェクトを宣言的に記述すると、DIコンテナが必要なオブジェクトを生成(かつライフサイクル管理もお任せ)してセットしてくれる

DIコンテナ

DIの副次的効果

- 目的のメソッドに引数を渡すために呼び出し途中のメソッドに不要な引数を追加するアンチパターン

- 目的のメソッドやオブジェクトにDIする

まとめ

- Webアプリのアーキテクチャの歴史の変遷を話しました

- 分割は設計の要ですが過剰な抽象化には注意しましょう

- パターンはフレームワーク化しましょう

- 世間一般で流布するパターンは部品をつなぐコードに偏りがちです

- なぜなら偉い人が見る/語る世界は必ずしも問題固有領域ではないからです

- 問題固有領域のパターンの発見は現場の人の仕事です

Webアプリのアーキテクチャの歴史と進化

Leave a Reply

著者一覧

カテゴリー

アーカイブ

最近の投稿

最近のコメント

メタ情報

公式リンク

2021年8月
月	火	水	木	金	土	日
« 4月
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Leave a Reply

著者一覧

人気記事

タグ

カテゴリー

アーカイブ

最近の投稿

最近のコメント

メタ情報

公式リンク