BodeAbp框架基于github开源框架ASP.NETBoilerplate，abp项目地址：https://github.com/aspnetboilerplate/aspnetboilerplate

BodeAbp系列博客：http://www.cnblogs.com/liuyh/category/853374.html

1. 官方文档：http://www.aspnetboilerplate.com/Pages/Documents
2. tkb至简博客：http://www.cnblogs.com/farb/category/740324.html
3. 阳光铭睿博客：http://www.cnblogs.com/mienreal/tag/ABP/
4. HK Zhang源码分析系列：http://www.cnblogs.com/1zhk/category/798531.html

1. 前后端分离（demo本身使用了vue。完全分离react示例在这里：https://github.com/liuxx001/react-demo）
2. 将EF的迁移方式改为自动迁移，并提供是否启用自动迁移的开关。
3. 功能模块化，使用abp提供的动态webapi实现功能模块的分离。
4. 由于Abp.EntityFramework改动较大，所以暂不支持按租户进行分库。
5. 添加一些工具类。
6. 提供一个bode.grid.js简化后台增删查改功能，增删改完全不用自己写代码。
7. 提供多数据支持，支持不同模块数据表分散在不同的数据库中，且支持自动迁移。

每个做过的项目都是有价值的，不管项目本身是成功还是失败，每个项目的代码都是我们的几个月甚至几年的心血。任何一个项目能让我们沉淀下来的东西我认为不仅仅是技术能力，也还有业务模块。一个新项目不应该是从零开始，而应该是在自身或者公司的技术以及业务积累之上开始。

好吧，接地气的说法就是我希望几年以后做项目是在业务模块库中拼拼凑凑，然后做一些细微调整就可以交给客户了。

1. 每一个业务模块应该是足够独立的，是能维护自身状态的。包括模型（数据表）、api、权限、菜单、设置项等。业务模块之间的依赖应该是尽可能小的。
2. 关于EF的自动迁移，有褒有贬，但是为了业务模块中模型（数据表）的独立，还是采用了自动迁移，毕竟如果添加一个模块，都要在模块之外的DbContext中加许多属性这个设计就真的太不好了。
3. 关于DDD，BodeAbp业务模块中并没有完全按照DDD的思想来设计，思想是方便和指导开发的，但总被思想束缚我认为也是不妥的，设计合理即可。当然也可能是我对DDD的理解还不够深刻。
4. 关于多租户，我另外创建了一个分支删除了所有关于多租户的代码，现在用不到也加大了业务模块的复杂度，后续时间空余后可能会提供多租户的版本。
5. 关于模块之间的通信，使用了abp提供的事件机制，模块间不会相互依赖，只会相互通知。

1. 外包公司
2. 喜欢接私单的小伙伴
3. abp框架的使用者

1. 框架着眼于业务模块的重用，在意的是业务模块的通用性，对于专业性特别强的如银行、医疗、保险系统帮助不是很大
2. 在宏愿完成之前，框架不能进行分布式部署，不适合互联网项目
3. 对于abp框架的升级以及bug修复的时间会落后于直接使用原abp框架。
4. 由于作者很懒，经常很久不更新，所以分享仅供交流，慎用。

让每个业务模块都能集群部署。