フレームワークとライブラリのどちらが望ましいか，という議論が起きている。Axon Fraameworkを開発するAxonIQのコマーシャルディレクタで，エバンジェリストのFrans van Buul氏は先日、ひとつのブログ記事を執筆した。ライブラリを支持する声が多い中で，Van Buul氏は、ビジネスアプリケーションの開発にはフレームワークの利用が非常に有用だ，という考えを述べている。Axonがアーキテクチャ概念として支持するCQRS、DDD、イベントソーシングを使用するアプリケーションには、これが特に当てはまる，というのが氏の意見だ。
Van Buul氏の定義するライブラリとは，クラスや関数で構成されたコード本体である。アプリケーションによって利用されるが、アプリケーションの一部ではない。アプリケーションはライブラリ内の関数やメソッドを呼び出すことで、ライブラリとのインタラクションを行う。一方のフレームワークについては、アプリケーションがそのインターフェースを実装したり、あるいはアノテーションを使用するという、別のインタラクション方法を備えた特殊なライブラリ形式である、というのが氏の定義である。実行時にはフレームワークがアプリケーションを呼び出す。ライブラリとは逆だ。
フレームワークを使わずにアプリケーションを開発するというのは非現実的だ，とVan Buul氏は言う。Javaプラットフォームのみを使う場合でも，それはフレームワークを使用していることなる。Javaプラットフォームはオペレーティングシステムとマシンを抽象化しており、プラットフォームがアプリケーションを呼び出すからだ。加えて氏は、大部分のアプリケーションがWebベースのインターフェースを備えており、アプリケーションのエントリポイント生成に抽象層を用いている点を指摘する。これもつまり，フレームワークを使用していることになる。
フレームワークを使用すべき理由として、Van Buul氏は、CQRS、DDD、イベントソーシングが要件である場合を挙げている。最初に言えることは、開発者がインフラストラクチャではなく、ビジネスドメインに集中することが可能になる、という点だ。ライブラリの使用はその現実的な代替手段にはならない，自身でフレームワークを構築する必要がある，と氏は考えている。これは結果として非常に複雑な作業となり、開発者はフレームワークの作成に多大な時間を浪費することになる。リスクもコストも要するこのような作業は避けるべきだ、と氏は強く主張する。そして、CQRSという用語を考案したGreg Young氏と、自身がDDD Europe 2016で行ったプレゼンテーションを引き合いに出しながら、次のようにアドバイスする。
CQRSフレームワークを自作する必要はありません。
一方でPeter Kummins氏は，フレームワークをシステム開発における最大のアンチパターンのひとつだと考えている。習得が難しい上に，プロジェクトの複雑性と依存関係を増大させるという意見だ。ソフトウェアは最小限の複雑性を持って開発し，今後20年間使用され続ける基本ツールを使用するべきである，そのためには汎用ライブラリやフレームワークよりも，コアな言語ソリューションと小規模な抽象化，あるいはヘルパライブラリを使用するべきだ，というのが氏の主張である。
Kummins氏がフレームワークを使わない理由は，次のようなものだ。
- 習得が難しい上に，その知識が他では役に立たない
- 創造性の範囲を制限する
- プロジェクトを複雑にする
- ビジネスをだめにする
Mathias Verraes氏は，フレームワークの定義に同意して，その一節を次のように引用している。
ライブラリはコードが呼び出し，フレームワークはコードを呼び出す
氏はフレームワークに反対する理由として，理解不足，時代遅れ，明らかに間違った抽象化といったコストに比較すれば，10年前のシステムにおける定形コードのコストは取るに足らないものだ，と主張する。従って，フレームワークを使用するのは開発ライフスパンの短いアプリケーションに限定し，長期間運用する予定のシステムには用いるべきではない，というのが氏の意見だ。
Tomas Petricek氏も同じフレームワーク定義を採用した上で，フレームワークの最大かつ最も明確な問題は，組み合わせることができない点だと述べている。2つのフレームワークを使用して一方を他方に合わせる方法は通常は存在しないが，ライブラリならば簡単だ。加えて氏は，フレームワークは内部を理解することが難しく，作成するコードにも影響を与える点を指摘している。
Petricek氏は関数型ライブラリの設計原則にも言及して，フレームワークとコールバックを回避する方法のひとつとして，非同期ワークフローとイベントベースのプログラミングモデルを挙げている。実装を要する抽象メソッドや仮想メソッドを書く代わりに，イベントを公開して，オペレーションが必要な時にトリガする方法である。このモデルではイベントがいつトリガされるか分からないため，それを完全に制御することはできないが，その後の処理については制御が可能だ。この方法でコントロールを逆転すれば，フレームワークを使わなくても，構成可能なライブラリを使用することや，問題の特定部分に使うライブラリを選択することが可能になる。
結論としてVan Buul氏は，ライブラリを支持する理由のひとつはその柔軟性にあるとする一方で，これは比較するフレームワークにもよる，と記している。フレームワークが拡張面で閉じられたものであることはおそらく事実だが，オープンインターフェースをコアコンセプトとして設計されたオープンソースのフレームワークであれば，柔軟性においてライブラリに引けを取ることはないはずだ。