コンセプト

Asakusa Frameworkの思想

「システムの本質は設計である。設計のないシステムでは品質は担保されない。品質のないシステムは適切な価値を利用者に届けることはできない。」

端的にいうと、Asakusa Framework（以下Asakusa）の考え方は、上記に基づいている。従ってAsakusaは設計オリエンテッドなフレームワークになっている。そして設計された内容をシームレスに最新の実装技術にそのまま展開できることを目標としている。（現在のターゲットはHadoopになっている）可能な限り設計から、そのまま実装に落ちることを目標にしている。

Asakusaが選択した「設計を優先する」ことのメリットは以下の通りだ。

品質を向上させる
システム全体の再利用性を上げる
トータルでの開発効率を上げる

またデメリットも甘んじて受ける。すべてに向いているフレームワークは存在しない。Asakusaが選択しなかった、しかるべきトレード・オフは以下の通り。

アドホックな開発をベースにする短期イテレーショナルなシステム構築は対象外。
品質よりも開発スピードを優先をするシステム開発は対象としない。
設計能力のない人材による力技の開発には向いていない。

順番にコンセプトを解説する。

設計をしっかり行うことで、そもそもそのシステムが何をしたいのか？どのデータをどう扱いたいのか？ということが明確になる。したがって、システムの意図が明確になり、あとから追いかけることが容易になる。システムの見通しの良さは、従う地図に依る。一度、理解をして記録をとった道筋に迷う人間はいない。システムの意図するところ、どのような挙動をとるか、を事前にはっきりさせることが設計である。しっかりした設計は、システム自体のテスタビリティを上げる。これにより結果として品質は安定する。品質が安定し、かつ挙動が理解できるシステムの再利用性は高く、また可搬性も高くなる。たしかに設計に工数を取ることは骨を折るだろう。また一時的には、時間がかかるかもしれない。ただし、その設計に割いた時間の何倍ものメリットが、システム構築の後半で得られる。Asakusaの開発は、「設計をせずにとりあえずつくってみましたデスマーチSI」のアンチテーゼでもある。

設計をせずにとりあえず作ってみましょう、という仕組みではAsakusaのメリットは生かせない。Asakusaは「データの入出力を規定し、それぞれのデータセットに対する処理を記述し、その処理をフローとしてつなげる」というそれだけ「しか」できない。見栄えの良いwebのデザインを生成したり、簡単にモバイルでのアプリケーションが生成できるようなものは提供しない。したがって、今現在モバイルやwebで必要とされる、「誰よりも早いwebサービスのリリース」のシステム構築にはまったく向かない。スピーディなサービスのリリースを否定するわけではない。ただ、Asakusaが目指しているものとは違うということだ。

設計を実装に移すためにAsakusaは、どのような道具立てを準備しているのか？設計から直接実装できるDSLを準備している。このDSLは、制限的なDSLだ。実装選択の余地はほとんどない。設計した通りに、データタイプを記述し、そのデータセットについて必要な演算を記述し、データフローを結線していく、基本的にはこれだけである。やれることが制限されているため、その結果、DSL自体の学習コストは低くなっている。

このDSLで記述を行う限りにおいて、分散処理の実装が自動生成される。また、同時にデータモデル実装の自動生成、テストプログラムも含めたテストドライバーの自動生成も行われる。「設計を行う」という手間のかかる作業の代償として、利用者は高度に分散処理された実装とそれを実行するためのトランザクションの仕組み、データモデル実装、さらにCIが可能なテストドライバーといったものを極めて平易に手に入れることができる。

「丁寧に設計することにより、実装のコストを下げることは可能である。」これがAsakusaの意図しているところである。