当需求明确后，开始编程第一步是做什么？
多年前，我的第一步是设计表结构。当时流行的工具是PowerDesigner，一个表结构设计工具。直到现在，我看到很多架构师、或者是技术Leader，依然是采用这种方式。我们称之为围绕数据库编程。
后来出现了RUP，会画出用例图、时序图、类图设计图，这些图有利于理清设计思路。这些图的核心是关注业务逻辑和业务实体，而不是数据库如何实现。
我们系统的核心是什么？是业务逻辑。而不是数据库、消息队列、微服务、REST、RPC等，这些都是细节实现方式。业务逻辑包括业务实体和用例，业务实体是描绘业务对象，包括属性和方法；业务用例是调用实体和其他细节（如存储）来完成具体用户功能。为了设计更加干净、容易修改的系统。我们应该围绕业务逻辑来编程，并且将业务逻辑和其他细节实现分开。这样代码才更容易修改。
比如一个在线考试。题库、考卷等是业务实体，题库维护、产生考卷并答题是用例。这些东西可以先不依赖任何细节编写。在用例中需要调用数据存取功能的，比如对题库的读写，可以写个接口。先用Mock模拟接口，用TDD对业务逻辑、业务实体进行测试。等最后需要集成的时候，再决定用什么数据库、协议、框架等来组成适当的功能。而业务逻辑并不依赖这些细节，你可以随时修改细节实现而不影响业务逻辑。
业务逻辑必须是简单的、原始的、不依赖任何细节的。比如业务逻辑并不知道数据库、消息队列、Controller、REST、Spring的存在，他不依赖他们。而是这些细节依赖业务逻辑。
高层不应该依赖细节，细节应该依赖高层。