规则指的就是一个软件的业务逻辑，也是它的价值所在。
等级我们可以理解为模块到输入和输出的距离，距离越远模块等级越高。
业务逻辑，就是可以使一个业务赚钱或者省钱的逻辑。
在任何业务中，都会有两个元素存在，业务逻辑和业务数据。
一个实体（Entities）就是指的一个同时拥有业务逻辑和业务数据的模块。
用例（Use Cases）, 就是一个描述一个自动化系统的用途。它描述了用户的输入，使用方法和期待输出的结果。用例描述并控制着用户和实体的交互。
由于用例更接近用户(I/O)，用例的等级就要比实体低，所以用例用该依赖于实体。
用例应该遵循请求（request）和答复（response）模式。给予一个输入返回一个特定格式的输出。但是却并不应该绑定到一个具体的框架（REST，SOCKET etc）。
重点
很多人可能会在用例所使用的请求和答复的数据结构中直接引用实体（Entity）的数据结构。一定要避免这样做。这两个数据结构的用途是完全不相同的，它们可能会由于不同的原因而被修改。
构架不应该依赖于框架，工具以及数据库等。构架应该围绕于用例和实体。如果你的构架只围绕着用例，那么你的所有用例都应该可以unit test。这些测试应该可以在没有服务器，数据库等的情况下运行。
在测试的时候，要避免一对一的测试。避免对每一个类，每一个方法进行测试。 一对一的测试是高度耦合的，这样的耦合性会导致代码难以扩展和重构。 我们应该针对use case测试，针对每一个模块所提供的API（核心方法）来进行测试。TDD Harms Architecture