架构分四层，我的代码应该放哪一层

我们的应用工程结构，常见大致分为四层。分别是api层、biz层、domain层和dao层。

要想清楚我们的代码应该放在那一层，先让我们一起熟悉这四层的职责。

图自https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww

一、api层

api层，正如它的名字一样，是提供api服务的。向谁提供api呢，比如客户端，比如APP端、pc端等等，公司外面的客户，比如isv等。可以看出来，它的特点是主外。是一种向外“表达”。有时候这一层，在特定场景下也有“视图服务层”的含义，它要负责不同客户端的展示前置逻辑，比如APP端要展示4个字段属性，pc端要展示10个字段属性。这种情况下也在这层处理。

特点：要灵活、要薄，能够随着不同业务定义特性的api。

二、biz层

biz层，也叫业务服务层。它主要负责编排。把一个业务场景下的主流程逻辑处理完成。这个主流程会涉及到多个原子接口，就在这层负责组装。可以看出来，它的特点是主内。是一种“向内”表达。这也是区别api层的地方，虽然有时候api层和biz层是1:1的关系，当然有时候也会有M:N的情况。但是，它的职责定位跟api完全不同。

特点：也要灵活、薄，另外要可以根据特定场景进行编写独立的biz类。

api层是不是冗余？文中的个人观点：不冗余。

api层并不冗余，虽然常见较薄，依然尤其独立的职责。譬如特殊业务的定制API、同一业务不同渠道（PC、APP）不同API、同一业务权限控制力度不同的API。

三、domain层

domain层，叫做领域服务层。按照OO思想，领域编程的思维，我们的”厚对象“的代码都在这层。比如订单域、运费域等。注意，在没有形成领域之前，这层一般叫service层，不过我们都是建议领域思维编写代码。

特点：要厚，要规范，沉淀复用为主。共用的逻辑在这层，但也可以通过SPI的形式去兼容个性化的业务逻辑，比如不同业务模式下，运费的模版不同，那么可以把这些个性的逻辑通过SPI扩展出去。

四、dao层

dao层，也就是我们的存储层了，负责持久化。

特点：也要灵活，能够随着不同DB之间的差异、以及性能的要求，独立dao的方法。

问题1：我们大量的代码应该放在哪层？

原则：厚domain薄biz

问题2：domain层一定要用充血模型吗？

原则：不必要

学习参考资料：https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww