アーキテクトがリードするUIプロトタイピング（OOSass と JavaScript MVC と DDD）

一連の模索中：

ここで、いったん、まとめておく。

思想

開発とは、すなわちプロトタイピングである。

手法

プロトタイピングをスケール（大規模化）するには、使いやすい部品を作って、それらを組み合わせることである。

アーキテクチャ

コンポーネント定義はIAが行うのが理想。かつ、それをデザイナーやフロントエンドエンジニアに伝達し、実装後にそれが維持されているかを確認するところまでが仕事。（『CSS PreprocessorとIAの親和性【その仕事、蠍は留守です】』）

自分なりに再定義しておく：

アーキテクトがプロトタイピングをリードする。
プロトタイピングのなかで HTML と CSS と JavaScript の基本的なモジュールを作る。
アーキテクトがハイレベルのアーキテクチャをコントロールしつつ、フロントエンド・エンジニア（やマークアップ・エンジニア）に詳細な実装作業を委譲する。

もちろん、フロントエンド・エンジニアからのフィードバックを受けてアーキテクチャを改善する必要があるのは言うまでもない。

以上はユーザー・インターフェイス層だけの話。それに加えて、アプリケーション層、ドメイン層、インフラストラクチャ層がある。合計４層。このすべての層をアーキテクトがコントロールする。

もちろん一人ですべてを作ることはできないので、各層の専門家とコラボレーションしながら。ペア・プログラミングなどの、密接で創造的なコラボレーションが大事。プロジェクト初期はワークショップ主体。

実装技術

OOCSS のアイデアに Sass を組み合わせた OOSass が有力。『Takazudolog - OOCSSとSass』によくまとまっている。

OOCSS で問題になっている「セマンティックでない class 指定」、言い換えると「スタイル指定そのものになってしまっている class 指定」については、オブジェクト指向の知見を導入して解決する方向で模索したい。

具体的には、宣言的な仕様として class に記述できるように CSS をモジュール化できないだろうか。『エリック・エヴァンスのドメイン駆動設計』でいうと「第10章しなやかな設計　設計の宣言的スタイル」など。

なんとなく、「コマンドと副作用のない関数の区別」のアナロジーで対処できる気がしている。作業仮説。

JavaScript については MVC フレームワークを導入する。システム全体としては「ユーザー・インターフェイス層」（UI層）だが、その UI 層のなかにも４層ある、と考える。つまり「UI サブシステム」の「ドメイン層」がある。 jQuery を使っていいのは「UI サブシステム」の「UI 層」だけ。

まあ４層は大げさかもしれない。『Backbone.jsにおけるModel-View-Presenterアーキテクチャパターン｜クラスメソッド開発ブログ』のように MVP の３層で十分にも思える。このへんは、やりながら考えたい。

現時点では Backbone.js よりも AngularJS のほうに興味がある。 AngularJS は MVC アーキテクチャで、『AngularJSを使ってみよう « NAVER Engineers' Blog』が分かりやすい。

続き：UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン