写代码这玩意儿，一开始图个快，功能能跑就行。但凡项目大了，人多了，时间久了，那真是噩梦的开始。文件像垃圾堆，改个小地方牵一发动全身，互相依赖缠成一团，跟意大利面似的，剪不断理还乱。这就是为啥我们要提分层啊。这不是啥玄乎的理论，是血泪教训换来的智慧结晶，尤其在Python这种灵活得过分的语言里，没个章法真不行。
你想啊，盖房子是不是要分层？地基是地基，承重墙是承重墙，内墙是内墙，装修是装修。各司其职，井井有条。你不能把电线埋在管道里，也不能把水泥当壁纸贴吧？软件也一样。把不同的职责区分开来，放在不同的“楼层”里，这就是最朴素的分层思想。
那Python里头，我们通常怎么“分”？没有一套官方的“标准层级”，但有些模式大家都觉得好用，用的人多了，也就成了事实上的约定。最常见、最基础的划分，大概可以掰扯成这么几层，从上往下说：
首先是表现层（Presentation Layer），或者叫用户接口层。这层最靠近用户。如果是Web应用，那就是负责接收HTTP请求、处理请求参数、调用下层的服务、然后把结果渲染成HTML或者JSON返回给浏览器。你想想Flask或Django里的视图函数（Views），它们干的活儿就属于这一层。它们只负责跟外部世界打交道，接过来，递下去，拿回来，展示出去，绝不应该在这里头直接处理复杂的业务逻辑，更别提直接操作数据库了。如果你的视图函数里塞满了复杂的计算、数据库查询和各种判断，恭喜你，你正在制造未来的麻烦。这层应该“傻”一点，像个前台接待员，只负责沟通和转达。
往下走，就是应用层（Application Layer）或者叫服务层（Service Layer）。这是核心区域之一，它负责协调工作流程，处理具体的业务场景。用户在表现层点了个按钮或者发了个请求，这个请求会转发到应用层对应的服务。比如用户要注册，注册服务会调用用户领域的逻辑、调用发送邮件的服务、调用日志服务等等。应用层本身通常不包含复杂的业务规则，它更像一个指挥官， orchestrates（编排）各种操作。它知道“为了完成用户注册”，我需要先验证输入，然后创建用户账号，再发一封激活邮件。具体的“创建用户账号”怎么做，“发邮件”怎么做，它不关心细节，交给更下层去干。这么做的好处是啥？你的业务流程清晰地展现在应用层，改一个流程，只需改这一层，下面更稳定的逻辑不用动。而且，如果你的应用层写得好，理论上你可以换掉上面的表现层（比如从Web换成命令行界面或者API接口），下面的业务核心和基础设施层都不用变。
再往下，是整个系统的灵魂——领域层（Domain Layer）。这层承载着你的核心业务规则、业务状态以及那些真正有价值的业务概念。用户、订单、商品、库存…这些不是简单的数据结构，它们有自己的行为、自己的规则。一个订单创建后不能随便修改，一个商品库存不足时不能下单…这些业务约束和行为就应该放在这里。领域层是系统的骨干，它是最独立、最稳定的一层。它绝对不能依赖上层（应用层、表现层），也不应该直接依赖基础设施层（数据库、第三方服务）。这里的对象（我们常说的领域模型）只关心自己的业务逻辑，它应该对外界一无所知。想象一下，一个Order对象知道如何计算总价，知道如何标记自己为已支付，但它不知道自己被存在哪个数据库里，不知道自己是怎么通过API暴露出去的。把最宝贵的业务逻辑放在这里，它就成了可重用、可测试、不容易被外部变化（比如换个数据库）影响的坚固核心。
最后，是基础设施层（Infrastructure Layer）。这层负责处理所有的“外部”细节，那些为了让系统跑起来不得不依赖的东西。比如：数据库访问（ORM如SQLAlchemy就在这一层扮演重要角色）、文件系统操作、调用第三方API（支付网关、短信服务）、日志记录、消息队列等等。这层是实现细节的集合，它依赖于特定的技术栈（SQL、HTTP请求库、Redis客户端等）。关键在于，领域层和应用层不应该直接跟这一层耦合。领域层里的Order对象不知道自己怎么被存到数据库里，这是基础设施层里的一个仓储（Repository）对象的工作。应用层调用order_repository.save(order)，这个save方法具体的实现（是SQL insert还是NoSQL put）就在基础设施层。这么设计，最大的好处就是可替换性。想换数据库？理论上只需要修改基础设施层里实现Repository的部分，上面的领域层和应用层可以完全不动。
分层不是硬邦邦的规定，更像是一种指导原则，一种思维方式。实际项目里，层数可能多一点，也可能少一点，命名也可能不一样。比如你可能还有一个独立的数据访问层（Data Access Layer – DAL），专门负责数据库交互，这其实就是基础设施层的一部分。或者你可能有一个适配器层（Adapter Layer），用来处理跟外部系统的接口转换。这些都是为了更好地隔离依赖，降低耦合。
为啥要这么费劲儿分层？核心就是那几个词：可维护性、可测试性、灵活性和团队协作。
* 可维护性：职责清晰，修改影响范围小。改表现层不碰业务核心，改数据库实现不碰业务逻辑。出问题了也好定位，知道去哪一层找茬。
* 可测试性：这是分层带来的巨大福利。尤其是领域层和应用层，它们不依赖外部世界（数据库、网络），可以更容易地写单元测试。模拟一下基础设施层的接口，就能独立测试业务逻辑，速度飞快。你想测试表现层？模拟一下应用层的接口，就能测试视图函数是不是正确调用服务、正确返回数据。这比测试一个什么都混在一起的大泥球容易太多了。
* 灵活性：前面说了，换个UI、换个数据库、换个第三方服务，影响范围被控制在基础设施层和部分应用层，核心业务逻辑稳如泰山。
* 团队协作：不同的人可以专注于不同的层。有人精通前端就在表现层捣鼓，有人熟悉业务就在领域层和应用层深耕，有人擅长数据库优化就在基础设施层折腾。大家各干各的，通过清晰的接口互相协作，而不是挤在一个文件里互相碍事。
当然，分层也不是没有代价。最明显的可能就是代码量会多一些，因为你要写接口、写适配、写DTO（数据传输对象）来跨层传递数据，不像所有东西混一起那么“直接”。有时候层分得太细了，简单的功能也要绕好几层，会感觉有点“过度设计”，甚至有点拧巴。尤其对小项目或者刚开始的原型，过度分层确实没必要，可能还不如快速迭代重要。但这就像投资，前期多投入一点精力构建良好的结构，后期回报是巨大的。
在Python里实践分层，我觉得有几个点特别要强调。Python太动态，太灵活了，一不小心就容易打破界限。比如，在领域层里不小心导入了ORM的代码，或者在表现层里直接写数据库查询。要靠纪律！靠代码审查！靠测试来约束！使用依赖注入（Dependency Injection）模式也能帮助你更好地管理层与层之间的依赖关系，让低层以接口的形式暴露给高层，而不是高层直接实例化低层的具体实现。还有，数据在层之间传递时，尽量使用简单的数据结构（如字典、Pydantic模型），而不是直接传递领域模型对象，这样可以进一步解耦。
说到底，Python怎么分层？没有唯一的标准答案，但核心在于“分”：分清职责，隔离关注点，降低耦合。从业务逻辑到技术实现，从用户界面到数据存储，把相似的、相关联的、互相依赖强的放在一起，把不相关的、变化频率不同的隔离开。别怕前期投入，一个清晰的分层架构，能让你的项目活得更久，维护起来更轻松，也能让你的团队少掉点头发。这是一种权衡，一种取舍，没有银弹，只有最适合你当前项目的方案。但至少，知道有分层这么个工具箱，遇到意大利面条代码时，你就知道该往哪个方向努力了。
评论(0)