1. ABP を学べば、他のフレームワークは必要ないのか？
Java の世界では Spring がほぼデファクトスタンダードで、初心者も熟練者も学び、研究し、実践で使っています。つまり、アプリケーション開発において Spring は避けて通れないフレームワークであり、モノリスでもマイクロサービスでも問題なく対応できます。Spring を学べば、Java 開発において（データベースやフロントエンドを除き、Java 言語そのものに関して言えば）他の知識を一切学ばなくても仕事ができると言っても過言ではありません。
では .NET には、Spring のようなフレームワークはないのでしょうか？ .NET の学習者がそれを学べば、どんな .NET の仕事でもこなせ、さらにはアーキテクトの役割も果たせるようなものは？ 私は、オープンソースの ABP vNext ならそれが十分に可能だと考えています。なぜなら、ABP は十分にシンプルで、習得が非常に容易だからです。入門してからしばらく継続すれば、実践を重ねるうちに徐々に深く理解できるようになります。重要なのは、オープンソースであるため、アーキテクトが真似したり学んだりするのに十分な情報量があることです。内部のモジュール設計思想も、モジュールのインストールや削除の方法も、生きた実装コードとして目に見え、触れることができます。私などは、ABP さえしっかり学べば、他のフレームワークは学んでも学ばなくてもよいとさえ思っています。学ばない理由は、他のフレームワークが総合力で ABP に及ばないからです（.NET の領域において）。誇張ではなく、これに勝るものは他にありません。学ぶ理由は、どんなオープンソースフレームワークでも ABP に取り込めるからです。ABP のフレームワークルールを理解していれば、統合は数分で完了します。
したがって、私の結論はこうです。もし御社の事業が垂直製品であれば、ABP を問題なく使えます。モジュールからモノリス、マイクロサービスまで対応し、迅速かつ効率的に進化できます。もし御社がプロジェクト型の納品であれば、ABP のモジュール性を再利用して開発コストを削減できます。もし御社が外注型のプロジェクトで、さまざまな納品に対応する必要がある場合でも、ABP は組み合わせることで素早く成果を出せます。これは故意に誇張しているわけでも、宣伝のために言っているわけでもありません。本当に便利で、使ってみればわかります。
2. ABP は難しいのか？
もちろん、ABP は入門は簡単ですが、熟達するのは困難です。何しろ基盤インフラであり、深い技術的な奥行きがあります。単なる利用者として留まるなら問題はなく、すぐに習得できます。私を信じてください。ある程度 .NET の基礎がある人なら、1 日で使い始められるでしょう。しかし、問題に直面したりカスタマイズが必要になったりすると、必ず困難にぶつかります。そうなると、断片的なモジュールの海で迷子になり、各モジュールは網目のように依存し合っています。モジュール化は非常に柔軟で、ソリューションを 4 層にするか 7 層にするか、あるいはそれ以上にするかは非常に重要です。なぜなら、DDD の階層モデルとビジネス要件を深く理解する必要があるからです。そのため、深く学ぼうとすると、ABP は簡単ではないと感じるでしょう。
3. ABP の存在意義は？
この質問は、「Java があるのに、なぜ Spring が必要なのか」と問うのと同じです。ABP が存在する真の意義は、開発者が早く帰宅し、幸せなプログラマーになることです。これは低い要求だと思わないでください。非常に難しいことです。プロジェクトは開発から運用まで、どの工程も簡単ではありません。プロジェクト初期は、進捗を出すために残業します。疲れはしますが、プロジェクトが進んでいるので疲弊はしません。プロジェクト後期は、自分のコードなら修正を受け入れられます。自分で書いたコードなので、修正方法がわかっているからです。プロジェクトの運用段階で、あなたが退職し、新人がコードを修正しながら首を振って文句を言い始め、プロジェクトは徐々に腐敗していきます。次々と新しい人材が手を加え、糞の山を積み上げていくと、プロジェクトは傷だらけでボロボロになり、それでも作り直すことはできず、コードは朽ちていきます。
これらはすべて、チームに規約がなく、メンバーのスキルにばらつきがあるためです。業界のベストプラクティスの地図がないからです。もし ABP がこれらの問題を解決する助けになるなら、その価値は当然高いです。.NET 開発者で転職が多い方なら、必ず多くのレガシーシステムを引き継いだ経験があるでしょう。多くのシステムは構築初日からすでにレガシーの痕跡を帯びています。全体を移行しようとすれば悪夢です。私は 10 年以上 .NET に携わってきましたが、成功事例を見たことがありません。チームの能力不足、コスト高、リスクが大きすぎる……。結局、すべての問題は初日に方向づけられてしまうのです。
プロジェクト管理やソフトウェア工学以外にも、技術面ではオープンソースの ABP から多くの優れたコード、アーキテクチャ設計、テスト規範、ベストプラクティスを学べます。簡単な例としてマルチテナントを挙げましょう。もしマルチテナント機能を使っているなら、その実装に感銘を受けるはずです。なぜなら、マルチテナントの存在をほとんど意識させないからです。おそらくそれがマルチテナントのエレガントさなのでしょう。DDD は言うまでもなく、その規範に従って進めれば、DDD についてより深く理解できるようになります。今まで貧血モデルで開発してきたのに、自分は DDD を知っていると思っていたことがわかるでしょう。
ABP の意義は、一言二言で語り尽くせるものではありません。それ自体が常に進化しており、オープンソースから吸収したエネルギーを間接的に私たちに示してくれています。私は今でも ABP を極めたとは言えません。なぜなら、入門は簡単でも、熟達するのは本当に難しいからです。熟達するには、かつて膨大な時間をかけて ABP をゼロから再構築した経験が必要でしょう。そうでなければ、どうして ABP を極めたと言えるでしょうか？
4. ABP は肥大化しているのか？
ABP は肥大化しているという声をよく聞きます。それがどの側面を指しているのかわかりませんが、単なる一般論であれば、非常に非専門的であり、その人は ABP を深く研究したことがないとすら言えます。DLL ファイルが多すぎるのか、起動が遅いのか、メモリを多く消費するのか。証拠を示さない限り、それは単なる印象論です。
本当の「肥大化」とは何か？
モジュール化は、業務や機能に応じて分割し、再利用性を高めるためのものです。分割が多くなると、学習が難しくなるかもしれません。なぜなら、たくさんのブロックがあり、それらに詳しくなく、説明書も手元にないと、まったく手が出せないからです。したがって、それは「肥大化」ではありません。レゴブロックを「肥大化している」と評する人はいません。むしろ、レゴは強力で柔軟性が高く、さまざまな可能性を実現できると評価します。ただ想像力が足りないだけであり、自分の想像力の欠如を理由にレゴを肥大化していると言うべきではありません。
複雑なシステムを管理するには、必然的にシステムを分類・分割する必要があります。そうしなければ、巨大なモノリスこそがより肥大化していると言えるでしょう。私の理解する「肥大化」とは、コードの結合度が非常に高く、二次開発が困難で、切り離せず整理もつかない状態です。また、開発が完了した後の運用・修正が困難で、修正を重ねるうちに限界に達し、結局ゼロから作り直さざるを得なくなることです。旧システムがオンラインのまま、新しいフレームワークで再開発し、飛行機を飛ばしながらエンジンを交換し、さらにデータベースの移行も行うのは、小さな会社にとっては非常に危険であり、深刻な場合はプロジェクトが即座に終了することもあります。なぜなら修正ができなくなり、新しく入ったメンバーは対症療法しかできず、会社は必然的に離職率が高くなるからです。したがって、私の結論は、コードの結合度が高いことが肥大化、二次開発が困難なことが肥大化、運用効率が低いことが肥大化です。もちろん、肥大化にはコンパイルが遅い、デプロイが面倒、パフォーマンスが低いなど、さまざまな側面があります。
ABP を肥大化と言う方にお聞きしたいのですが、具体的に何を指しているのですか？ モジュール化した後、チームごとにコンパイルが遅くなるのでしょうか？ モジュール化した後、モジュールを個別にデプロイすることも、統合デプロイすることもできますが、それが肥大化なのでしょうか？ ABP で機能を実行するのが遅いのでしょうか？ すべてのモジュールは起動時にメモリに事前ロードされるので、どこが遅いのでしょうか？ 多少のメモリを多く消費し、多少の領域を使って、より高速なパフォーマンスを得ているにすぎません。
ですから、ABP を肥大化と言う方には、一般論で語らず、「肥大化」の前に限定詞を付け、実際の事例をもって議論していただきたいと思います。
5. おわりに
ABP は非常に優れているため、私は多大な労力を費やして ABP を深く掘り下げてきました。極めたとは言いませんが、何度も夜更けに ABP のソースコードを探求し、多くのドキュメントも読みました。ABP の入門は本当に簡単です。しかし、さらにその神秘的なベールを剥がしたいなら、おそらく私のこのシリーズの翻訳が、より早く、より深く学ぶ助けになるでしょう。学びを得て、楽しく学習できることを願っています。
もしあなたも ABP を学んでいて、相談したいことがあれば、ABP の QQ グループ（無料）にご参加ください。
または、私の知識星球（有料）にご参加いただければ、より迅速で包括的なサービスをご利用いただけます。
以上の共有がお役に立てれば幸いです。ご拝読ありがとうございました。
作者: [張飛洪廈門
QQ グループ: 共享交流群
私の: 知識星球