零基础ASP.NET Core WebAPI团队协作开发
相信大家对“前后端分离”和“微服务”这两个词应该是耳熟能详了。网上也有很多介绍这方面的文章，写的都很好。我这里提这个是因为接下来我要分享的内容和这个有些关联。
随着前端应用场景的繁荣，用户体验需求的提高，原先传统的后端渲染页面返回给前端展示的模式面临挑战。后端工作除了处理数据逻辑还得适应界面UI的业务，越来越不堪负重。前端的重要性逐渐体现出来，在这种情况下使用前后端分离模式开发的逐渐增多。
前端框架（比如Vue/Angular/React）的发力，大厂的推广使用，前后端分离已经很成熟。包括传统信息化这块以前使用传统WebMVC模式的开发的BS应用有些都逐步转为前后端分离模式。特别是开发人员分工之后专注做好各自的工作，效率更高，做出来的产品也就更好。
一、应用场景
1、浏览器端（Vue/Angular/React）+服务端API
2、桌面客户端（mfc/winform/wpf）+服务端API
3、移动客户端（各种App/App内置浏览器）+服务端API
4、其他终端（大数据展示平台/报表展示平台）+服务端API
客户端越来越强调轻量化，交互体验，不在满足于能用。服务端端只管提供API数据，这样业务逻辑大多在服务端处理，随着需求增加服务端的模块会越来越多。但是有些接口是共用的，有些是根据业务变动的，还有的API新旧版本过渡更新替换等等是服务端api要考虑的事情。设计好API开发框架面灵活应对这么多场景就很有必要了。
原先可能会做一个单体式应用，把所有用到的接口都加进去。但这样粒度很粗，如果某个场景下只使用了部分接口，那也得把这整个应用部署，无法做到按需添加。还有就是可能要修改其中部分方法，需要整体重新编译发布。这都存在可能影响其他模块的风险。
服务端任务量大了，怎么分工？这个时候单体明显已经不适用了。这里就引出了微服务。对微服务可能每个人有不同的理解，但有一点是有共识的，就是把一个大的单体式应用根据功能模块拆分，这样粒度细分之后很多接口就可以共用。之后的修改增加都是可以按需发布部署，局部出现问题不会影响整体。
这个服务的粒度怎么拆分也是需要慎重考虑的问题。除了功能拆分还得考虑人员匹配。
案例场景：一个系统有10个子系统（模块），每个子系统（模块）又有10个功能，每个功能再具体又可能有20个左右的方法代码。
这个案例，最后大概有2000个方法代码。
如果开始安排10人的团队开发，中途因为项目紧急再增加了10个人进来，总共变成了20人，项目组怎么做才能快速适应这种人员变动。
有时候不是人越多越能做好事情，在人员增加情况下除了增加沟通协调成本，实际情况会遇到新加的人参与进来的门槛很高，不能快速着手展开工作，有时候还会出现不知道从何入手的困境。这就是因为拆分的不合理，任何的改动可能会影响到他人。这样虽然为了赶进度加人了，但实际的效果却不是很理想。
二、功能拆分分析
怎么拆分这有两个极端例子
1、粒度最粗，全部在一个解决方案（极端例子，类似单体式应用，适合一人开发）
2、粒度最细，细分到每个方法一个解决方案（极端例子，实际肯定不会这样做）
实际项目中功能拆分就是在这两个极端情况之间找适合的平衡点。具体拆分到多大的粒度，这个就只能是根据具体项目情况具体分析了。但是微服务可能是建议往细的方向拆。
如果是项目型的会发现如果拆的太细，上线一套系统要带N个接口，运维实施都很麻烦；如果是做平台型的产品可能就是有限的几套系统，不会随着项目铺开太多定制化。也就没有了项目型里面的经常部署实施等繁琐的问题。