拆分是任意的。随意给一个标准，我们都可以把任何东西按照这个标准给拆了。以下是我给的拆分角度：
业务逻辑可以被拆分成：
- 编辑时：拆分成文件、文件夹、Git仓库
- 运行时：拆分成进程
这个定义当然不是啥金科玉律。但是它在2020这个时间点的科技树而言，对于大部分开发者来说都是适用的。
这种拆分标准屏蔽了不同编程语言和编程框架的影响，我们不用争论什么是Class，什么是Module，什么是Package。
- 文件：大部分编程语言都使用了文本文件。只有非常少量的编程语言有自己的 Projectional Editor，这些语言的开发者面对的编辑界面和文件上存储的内容需要通过 IDE 进行映射。
- 文件夹：绝大部分开发者使用的操作系统，对于每一个文件都有所存放的文件夹的概念。一个文件从属于唯一的一个文件夹。部分操作系统在从属关系之外，还有链接，把两个文件建立关联。文件夹与文件夹呈树状组织。
- Git仓库：绝大部分公司会把代码拆分成多个Git仓库。Google等公司没有采用多Git仓库，而是全公司所有人在一个巨型的monorepo上工作。大部分公司切分Git仓库的主要目的是控制访问和版本。不同的开发者控制不同的Git仓库，从这个仓库下的代码产出整个仓库意义下的版本。
业务逻辑在编辑时需要拆分成文件、文件夹、以及Git仓库。那么从Autonomy，Consistency，Feedback这三个角度，如何评价拆分出来的结果，又有哪些拆分模式呢?
这种拆分标准屏蔽了不同运行环境的影响，无论是 iOS 设备上的 App，还是 apple.com 这个域名背后的服务器，软件总是运行在进程里的。
- 手机桌面上的App图标：从用户的角度来说，两个图标就是两个App，是两个不同的东西。
- 网站的域名：对于用户的角度来说，两个域名就是两个网站。
- 网络游戏：对于用户的角度来说，我们一起刷的副本，那就是同一个游戏。
运行时的表面现象太多了。我们可以随意给一个标准，比如两个界面有什么本质不同呢? 我们可以说不同 URL 的界面是两个“页面”。但是也完全可以 URL 不变，使得界面处于完全不同的两个状态。这样的情况下，这算两个页面还是同一个页面呢? 所以避免拆分出来的东西见仁见智，我们只能选择不那么用户可见，但是又相对稳定的东西。想来想去，也就是进程是歧义比较少的东西。
- 如何拆分文件，文件夹，Git仓库：目标是“代码防腐”
- 如何拆分进程：目标是“只负责自己写的代码”
- 如何分层：这个其实也是分 Git 仓库，目标是“突出大逻辑，隐藏小细节”
相比堆砌 MicroService，Domain Layer 这样的辞藻，更能穿透表面现象，看到事物的本质。到头来，总归是文件，文件夹，Git仓库和进程这些东西。