1. With ABP, do I still need to learn other frameworks?
Sometimes I wonder: in the Java world, Spring basically dominates. Both beginners and experts spend their time learning, researching, and practicing it. That is to say, for application development, Spring is an unavoidable framework. Whether for monolithic or microservices, it handles everything effortlessly. Once you learn Spring, you don’t really need to learn any other knowledge in Java development to land a job (excluding databases and frontend—I mean the Java language itself).
So, is there a framework in .NET similar to Spring, such that after learning it, .NET developers can handle any .NET job, or even take on an architect role? I believe the open-source ABP vNext is fully capable of this. It is simple enough, very easy to get started with, and once you do, you can gradually deepen your skills through real projects. Importantly, the amount of open-source information is sufficient for an architect to imitate and learn from—whether it’s the internal modular design philosophy or the way modules are installed and removed, it’s all live, tangible code that puts the concept into practice. Sometimes I even think that if you master ABP, you can either skip or learn other frameworks. Skip because, from a comprehensive perspective, no other framework in the application layer can currently match ABP (in the .NET domain)—and that’s not an exaggeration. Learn because any open-source framework can be absorbed and integrated by ABP; as long as we understand ABP’s framework rules, integration is a matter of minutes.
So, my conclusion is: If your company’s business is vertical products, you can use ABP without issue, as it scales from modules to monoliths to microservices, allowing rapid and efficient evolution into microservices. If your company’s business is project-based delivery, you can reuse ABP’s modularity to reduce development costs. If your company does outsourced projects with diverse requirements, ABP can still deliver results quickly through combination and permutation. I’m not exaggerating or just promoting it—I truly believe this thing is very convenient. Those who use it know.
2. Is ABP difficult?
Of course, ABP is easy to get into but hard to master. After all, it’s an infrastructure framework with deep technical depth. If you only stay at the usage level, it’s no big deal—you can pick it up quickly. Trust me, if you have some .NET foundation, you might get started in a single day. But once you encounter problems or need customizations, you will definitely hit difficulties. At that point, you’ll find yourself lost in a sea of fragmented modules, with net-like dependencies between them. Modularity is very flexible—whether a solution should be split into 4 layers or 7 layers, or even more, requires careful consideration because you need to deeply understand DDD layering models and business requirements. So, when you need to dive deeper, you’ll find ABP is not easy.
3. What is the purpose of ABP?
Asking this is like asking why we need Spring when we already have Java. The real meaning of ABP is to let developers leave work early and be happy programmers. Don’t think this requirement is low—it’s actually very difficult. Because from development to operations, not a single stage is easy. In the early stages of a project, we work overtime to meet deadlines—tiring but not exhausting, because the project keeps moving forward. In later stages, you can accept constantly modifying code because it’s your own code, and you know how to fix it. During the operations phase, you leave the company, and new people modify your code while shaking their heads and cursing. The project gradually deteriorates. As wave after wave of new people keep adding to the mess and accumulating technical debt, your project becomes battered and scarred, yet cannot be thrown away and rebuilt. The code slowly decays.
All this happens because the team lacks standards and consistency—there’s no map of industry best practices. If ABP can help us solve these problems, then its value is naturally high. If you’re a .NET developer who changes jobs frequently, I’m sure you’ve taken over many legacy systems. Many of them showed signs of being legacy from day one. If we need to do a full migration, it’s a nightmare. In my 10+ years of .NET, I’ve never seen a successful case—either the team lacked capability, the cost was too high, or the risk was too great… In short, everything is set in stone from day one.
Beyond project management and software engineering, from a technical standpoint, we can also learn a lot from open-source ABP: classic code, architectural design, testing standards, and best practices. Let me give a simple multi-tenancy example. If you’ve used multi-tenancy, you’ll likely be impressed by ABP’s implementation—you almost don’t feel its existence. Perhaps that’s the elegance of multi-tenancy. As for DDD, no need to elaborate—if you follow ABP’s specification, you’ll gain a much deeper understanding of DDD. You’ll realize that the anemic model approach we used before didn’t truly understand DDD.
The significance of ABP is truly beyond a few words, especially since it keeps evolving with the times. The energy it absorbs from the open-source community is indirectly shown to us. Even now, I don’t claim to be proficient in ABP, because while it’s easy to get started, mastery is not easy—that would mean you’ve spent a lot of time rebuilding ABP from scratch. Otherwise, how dare you say you’ve mastered ABP?
4. Is ABP bloated?
I often hear people say ABP is bloated. I don’t know what aspect they are referring to. If it’s a general complaint, I think it’s quite unprofessional—I’d even say the person hasn’t deeply studied ABP. Is it too many DLL files? Slow startup? High memory usage? Unless you can provide evidence.
What is true bloat?
Modularization splits based on business or functionality for reuse. More splits may make learning harder because there are many blocks; if you’re not familiar and don’t have a manual, you won’t know where to start. That’s not called bloat. Would anyone call LEGO bloated? On the contrary, we find LEGO powerful and flexible, enabling many possibilities—unless you lack imagination. Don’t blame LEGO for being bloated just because you lack imagination.
Managing complex systems necessarily requires classification and splitting; otherwise, a big monolith is even more bloated, right? In my understanding, bloat means very high code coupling, making secondary development difficult—tangled and hard to unravel. Also, after development, maintenance and modification are tough, to the point where you can’t move forward and have to restart from scratch. With the old business still online, you have to develop a new framework while flying the plane and changing the engine, plus migrate the database. For a typical small company, this is very dangerous, and in severe cases, it can directly kill the project—because you can’t modify it anymore, and new hires just slap on patches. The company will inevitably face high turnover. So, my conclusion: high coupling is bloat, difficult secondary development is bloat, inefficient maintenance is bloat. Of course, bloat can also mean slow compilation, troublesome deployment, poor performance, etc.
I want to ask those who say ABP is bloated: what exactly do you mean? After modularization, does compilation become slow for each team? After modularization, modules can be deployed separately or integrated—is that bloat? Does running features on ABP become slow? All modules are preloaded into memory at startup—where is the slowness? It just consumes a bit more memory; using more space in exchange for faster performance—what’s wrong with that?
So, to those who call ABP bloated, please don’t speak in generalities. Add a qualifier and share actual cases to discuss.
5. Conclusion
Because ABP is excellent, I’ve invested a lot of effort into studying it deeply. I wouldn’t claim mastery, but I’ve explored ABP’s source code many times late at night and read a lot of documentation and materials. Getting started with ABP is really easy, but if you want to uncover its mysteries further, perhaps my series of translations can help you learn it faster and deeper. I wish you fruitful and enjoyable learning.
If you’re also learning ABP and have questions, you’re welcome to join the ABP QQ group (free).
Or join my Knowledge Planet (paid) for more timely and comprehensive service.
I hope the above sharing is helpful. Thank you for your attention.
Author: Zhang Feihong [Xiamen]
QQ Group: Sharing & Exchange Group
My: Knowledge Planet