比如上面的案例，一般都是先根据子系统拆分，具体到每个子系统，有一人或多人开发也有后期临时加入的情况。每个子系统一套接口还是比较合适的。
实际情况项目型比较多，考虑实施运维情况拆分的粒度不会太细，让实施去部署太多业务接口会把他们逼疯。如果有和我类似情况的下面的方案提供了一种解决办法。开发时候可以横向任意扩展，新加入的人员分配任务清晰，不用担心有耦合冲突。发布部署也不会因为粒度太细，增加部署工作量。总结就是插件式开发，微服务部署。
我们都知道vs里面建立一个解决方案，两三个开发人员在同一个解决方案里面开发，只要协调好还行，如果再加入人员，参与的开发人员一旦多了，就算分工好做各自模块，但还是会存在一个些冲突，比如增加文件，增加引用等等都会引起项目文件或者解决方案文件冲突问题。而且这种情况代码权限还不好细分控制。
最好的方式是每个开发人员做的事情都在自己的解决方案里面，只要是公共使用的引用协调好大家使用统一的版本，其他的自己完全可控，完全不用担心影响他人，或者他人的修改影响自己。
大家可以看下这个 https://github.com/dotnet/corefx/tree/master/src，如图1。
图1
这是dotnet基础库的源码，每个基础类库都是单独一个解决方案维护，随便点一个进去看下，如图2
图2
每个类库都有独立解决方案文件。
微软肯定有更好的方式去管理，但从这里可以看出，独立开发维护的优势。
三、接口项目准备
前面分享过一篇《零基础ASP.NET Core MVC插件式开发》的文章，那边文章其实也就是强调团队开发的时候能做到尽量独立，可以横向扩展，项目灵活变动增加开发人员可以快速参与，开发之后能汇总到一个个的子系统，最后完成整体开发。在这里API的开发也可以使用类似方案，因为API没有视图部分，处理起来比MVC简单。
接下来重点介绍该方案在API开发中的使用。开始这部分内容之前先简单介绍我这边API项目开发总结的两个共性问题：
1、使用swagger显示API文档（nuget 引用 Swashbuckle.AspNetCore）
因为API是没有试图的，为了可视化，以及方便测试，使用swagger作为API的展示界面。具体使用看下面提供的demo代码
2、使用版本控制API版本号（nuget 引用Microsoft.AspNetCore.Mvc.Versioning）
版本控制对API也是同样重要，看BAT大厂提供的API都是有版本控制的，要向他们看齐。实际应用中，程序不可能维持一套最新，有时候新旧版本需要过渡，所以需要有版本来区分。这里使用微软提供的版本控制。具体使用看下面提供的demo代码
这两个使用这里就不细说了，穿插下面主题做些简单介绍，具体看案例demo就可以。
四、接口插件式开发
回到我们的主题，这里重点介绍下一个子系统（模块）任务拆分与人员分工
项目组接下一个项目，一般有个开发组长，着手模块划分并且开发任务分工
组长（公共部分接口+核心功能模块接口）
组员1：细分的模块插件1接口
组员2：细分的模块插件2接口
组员3：细分的模块插件3接口
......
......
对于的解决方案结构，具体命名自己可以根据喜好自己自定义。
Agile.ModuleName.API 如下图3
Agile.ModuleName.Plug1.API 图下图4
Agile.ModuleName.Plug2.API
Agile.ModuleName.Plug3.API
......
......