大家好，我是张飞洪，谢谢你阅读我的文章。
自从土牛Halil ibrahim Kalkan的《Mastering ABP Framework》出版之后，我就开始马不停蹄进行学习阅读和翻译，目前基本保持一周两章的进度，具体内容试着点击【跳转阅读】
ABP的官方文档应该是比较全面了，但是有几个问题：
我曾想过叫《精通ABP框架》，但是整本看完，距离精通其实还是很远，我理解的精通是能从0-1搭建ABP框架，至少熟练源码设计精髓，犹如庖丁解牛，别人看到的是牛的身体，而庖丁看到的是牛里面的骨架和纹理。
如果直白翻译为《掌握ABP框架》、《ABP框架专家》，又感觉和整书的意境不一致，没有把整书的精髓拿捏住，因为框架是一种设计思想和理念，看不见摸不着，你怎么去掌，怎么去握呢？
当然快速入门等之类的翻译肯定也不行，因为书还是很厚，内容很干，根本不可能走捷径。想来想去先叫《玩转ABP框架》，好比古诗词，你怎么去翻译床前明月光呢？要不要意境？先暂且这么叫吧，如果你有更好的命名方式，欢迎您提供宝贵意见。
大家可以浏览一下亚马逊整书目录，全书分成四个部分，十七课时，内容从简单到复杂，从整体架构到细节代码，从架构问题到最佳实践，从基础架构模块到DDD，从动态API到模块化设计到架构演化，最后还讲解了自动化测试等等，内容十分精彩，也非常全面。
翻译是一次精神之旅，好比老牛吃草，需要咀嚼和消化再产出的过程。是典型的消费者到生产者的迭代循环模式。基本上要把书籍掰开揉碎，吃到肚子里回炉再造的一个过程。所以，翻译对个人的成长帮助很大，因为学习本身就是不断输入和输出的过程，通过输出倒逼自己不断输入，先把背包甩过墙体，再慢慢爬墙，直到翻过去为止。
翻译是一项苦力活，因为我既想保留原著的味道，又希望翻译后的内容是符合汉语的味道，不但在阅读顺畅，又能去除英文的部分啰嗦，可以说翻译整本书是不断输入和输出的迭代，是魔鬼细节的校对，也是措辞的反复咀嚼的过程。
我的翻译方式是，翻译一章实时发布一章，一般是晚上翻译，睡一觉，第二天起来校对细节，为了尊重原著，也为了对得起读者，我每翻译一章就Review两遍，这样确保脑袋是清醒，措辞和理解不会有大的偏颇，所有的努力就是希望能回馈读者，我相信你在整个阅读过程一定能体验到我的用心。
【目录跳转】
我有时候在想在JAVA领域，Spring基本一统天下，新手也好，高手也罢都在学习、研究和项目实战。也就是说其实对与应用开发，Spring已经是绕不开的框架，不管是单体还是微服务都可以轻松胜任，学了Spring在JAVA开发层面，其实你可以完全不需要去学习其他的任何知识点，也能参加工作（当然不包括数据库和前端，我这里指的是JAVA语言本身）。
那么在.NET有没有类似Spring的框架，让.NET学员学完之后也可以胜任任何.NET工作，甚至能胜任架构师的角色，我觉得对于开源的ABP vNext来说，是完全可以做到的。因为它足够简单，上手非常容易，只要入门之后持续一段时间，我们就可以不断地在实战中逐步深入，重要的是开源的信息量足够一个架构师去模仿和学习，不管内部的模块化设计理念，还是模块化安装和删除的方式，都是一个理念活生生的落地代码，看得见摸得着，甚至我有时候觉得，只要学好ABP其他的框架可学可不学，不学是因为其他的框架从综合素质来说，目前还没有看到一个框架在应用层面可以和ABP媲美（.NET领域），没有夸张地说没有之一。学是因为不管是任何开源的框架都可以被ABP吸收并蓄，只要我们自己懂得ABP的框架规则，我们的集成是分分钟的事情。
所以，我的结论是，如果你们公司的业务是垂直产品的，可以用ABP没问题，因为它可以从模块到单体到微服务兼容，到微服务做到快速而高效的演化；如果你们公司的业务是项目型的交付，也可以重复利用ABP的模块化来降低开发的成本；如果你们公司是外包型的项目，面对交付各种各样，ABP一样可以通过排列组合来快速交付成果。我这里不是故意夸大，也不是为了宣传而宣传，而是真的觉得这玩意儿真的是很方便，谁用谁知道。
当然ABP入门容易，进阶困难，毕竟他是基础设施，里面有很深厚的技术深度，如果你只是停留在使用的角度，那么问题不大，可以很快入门，请相信我，对于有点.NET基础的人，可能一天就上手了，但是一旦遇到问题或者需要定制，那么你一定会遇到困难，这个时候你会迷失在碎片化的模块海洋，而且每个模块之间又有网状般的依赖关系，模块化是非常灵活的，一个解决方案你要分4层还是7层，甚至更多都是很有讲究的，因为你要深入理解DDD分层模型和业务需求。所以，当你需要深入学习的时候，你会觉得ABP不容易。
问这个问题就好比问我们有了Java，为什么还要有Spring。ABP存在真正的意义是让开发人员早点下班，做一个幸福的程序员。不要觉得这个要求很低，这非常困难。因为项目从开发到运维没有一个环节是容易的。项目初期，我们会为了进度加班加点，虽然累但不感觉疲惫，因为项目一直在推进。项目后期，你不断修改代码也可以接受，因为都是你自己写的代码，你知道怎么修改。项目运维阶段，你离职了，新人一边修改你的代码一边摇头骂娘，项目开始慢慢变质。随着一波又一波的新人不断折腾和累积屎山，你的项目遍体鳞伤、伤痕累累确又无法推倒重来，代码开始慢慢腐朽。
所有的这些都是因为团队缺乏规范，人员层次不齐，因为你没有一个行业最佳实践的地图。如果说ABP能帮助我们解决以上这些问题，那么它的价值自然不低。从事.NET开发人员如果您跳槽频繁的话，我相信你一定接手过很多遗留系统，很多系统从构建的第一天可能有了遗留系统的痕迹，所以如果我们要进行整体迁移，那就是一场噩梦，我干了10来年的.NET，真的还没见过成功的案例，要么团队能力不够，要么成本太高，要么风险太大……总之，一切问题都在第一天就定了基调。
除了项目管理和软件工程方面，在技术方面我们一样可以从开源的ABP身上学到不少经典代码、架构设计、测试规范、最佳实践。我举一个简单的多租户的例子，如果你有在用多租户，你一定能对它的多租户印象深刻，因为你好像感觉不到多租户的存在，也许这就是多租户的优雅之处。至于DDD就更不用说了，你跟着它的规范走一遍，你对DDD会有更加深入的了解，原来我们以前一直在用的贫血模式开发就觉得自己懂得了DDD。
ABP的意义真的不是三言两语能说的完的，毕竟它自己也不断与时俱进中，它本身从开源身上吸收的能量也在间接展示给我们看。我到现在都觉得自己不能精通ABP，因为它上手容易，精通真的不是那么容易，因为这意味着你曾经花费很大的时间从0到1重构了一次ABP，否则你怎么敢说自己精通ABP呢？
我经常听到有些人会说ABP很臃肿，我不知道他是指的哪一方面，如果只是泛泛而谈，我感觉是很不专业的，甚至我可以说对方根本没有深入研究过ABP。是Dll文件过多，还是启动很慢，还是吃内存，除非你能拿出证据来。
模块化是根据业务或者功能的一种拆分，目的是为了重用。拆分多了，你可能学习了会有点困难，因为那么多块块，如果你不够熟悉，身边没有一份说明书，你根本就无从下手。所以，那不是叫臃肿，我们有人会评价乐高很臃肿吗？相反，我们会觉得乐高很强大，很灵活，可以实现各种可能，除非你缺乏想象力，不要用自己想象力的缺乏来说乐高是臃肿的。
管理复杂系统必然要求我们对系统进行分类拆分，否则一块大单体岂不是更加臃肿？我理解的臃肿是，代码耦合度非常高，进行二次开发很困难，剪不断理还乱。另外开发完了，要进行运维修改很困难，甚至出现改到后面，改不动只能重新推倒重来，在旧业务online情况下，新框架要重新开发，变开飞机变换引擎，中间还要做数据库迁移，对于一般的小公司只是非常危险的，严重的会直接宣告项目死刑，因为改不动了，然后新进的人员也只想贴膏药，公司必然存在离职率高的问题。所以，我的结论是代码耦合高是臃肿，二开困难是臃肿，运维低效是臃肿。当然臃肿还有很多内涵，比如编译缓慢、部署麻烦、性能低下等等。
我像请教那些说ABP臃肿的人，你到底在说什么？模块化后，团队各自编译会缓慢吗？模块化后，模块可以单独部署也可以集成部署是臃肿吗？你使用ABP跑功能会很慢吗，所有的模块都在启动时候就预先加载到我们的内存里了，哪儿慢了？无非多耗费一点内存，多用一点空间换取的不是更快的性能是什么？
所以，请那些说ABP臃肿的人，不要泛泛而谈，请你在臃肿前面加个定语，然后用真实的案例来和大家交流。
因为ABP很优秀，所以我花了很大的精力对ABP进行了深耕，不敢说精通，但是不止一次在深夜探索ABP源码，也阅读了许许多多的文档资料，ABP入门真的很容易，但是如果你一想进一步窥探它的神秘面纱，也许我的这个系列翻译应该可以帮你更快、更深入地学习它，祝你学有所得，学得快乐。
如果你也在学习ABP，也有遇到问题需要讨论，欢迎你加入我们的Q群：
除了《Implementing Domain Drive Design》是免费的，目前《Mastering ABP Framework》属于收费书籍，原书亚马逊售价是295.08人民币，所以本书的翻译暂时不能做开源处理，请大家理解。另外因为我不知道如何对接版权问题（目前还在了解当中），如果有侵犯到版权问题，请立刻和我联系删除。具体版权沟通情况，敬请等待。
