2019-09-20希望每篇都结合一点点实例程序架构作者回复: 好的👌
1 20- 2019-09-21明白了一些东西，老师比如我做一个接口，这个实现可以放在server层！ 之后公司内部调用逻辑可以放在web层！而哪一天公司要开放这个接口，那我最好是新抽象一层出来(一个新的服务)就是开放平台层！这样做的好处是，可以讲自家使用和第三方使用做隔离！比如在提供服务时，为了保证自家接口性能，对开放平台层做限流处理！
作者回复: 👍
18 
2019-09-20这里有个误导？我们所谓的独立部署并不是按照层次来部署。而是服务。因为不可能一个项目只部署controller，一个服务只部署dao层的。更多的是每一个服务按照这种层次来写。作者回复: 可以的呀 数据访问层也是可以独立部署的，controller也是独立部署的web服务
11 6
2019-09-26getuser之后创建user的案例，如果不加manager层，在service的getuser方法中做以下逻辑判断呢
if(未获取到用户){
this.createuser();
}
这样做有什么不妥吗~~望指教展开作者回复: controller层的逻辑有区别，一种是需要创建用户，一种是不需要，需要提供两个service方法，每个方法编排不同的manager层的原子方法。当然也可以提供一个service方法，使用不同的参数来区分。但这是一个简单的例子，引申来看，同一个服务接口，针对不同的场景可能会有一些差异，这种差异要在service层屏蔽，不应该蔓延到controller层
5
2019-09-24老师你好，我之前也看过很多次阿里的代码分层规范，一直对service层和manager层有点混淆不清，所以想请教一下老师我下面理解的分层是不是合理的
1. controller层接收客户端的请求
2. service层调用manager层和dao层处理业务
3. manager主要对service层通用的代码的沉淀，例如对多个dao调用的组合（逻辑意义上的连接查询），以及缓存等中间件的调用，并且在manager层处理事务
4. dao层主要放mybatis逆向工程生成的代码以及自己写的查询方法
不知道自己这样理解正不正确，还有就是事务处理应该放在哪一层，是在manager层还是应该在service层？展开作者回复: 在我来看业务逻辑放在manager，service来编排manager的原子服务
2 5
2019-09-21参数校验，放在哪作者回复: 业务类的校验放在service层，一般性的参数校验可以放在web层，可以通用化
4 5- 2019-09-20架构不分语言。我司主力语言php 架构至上而下是这样controller+module(service)+class(manager)+dao。第三方的调用服务也都封成基础类来调用了。基本上跟您讲的思路一样呢
作者回复: 是的呢
3 5 
2019-09-23感觉图有点问题。补下个人理解，共同探讨。
1.通用层改名领域层，个人习惯。
2.数据层同领域层也有交互。领域层交互数据层主要做业务；service层交互数据层主要开放接口，提供外部支撑。这块还涉及crud，读与命令分离。
3.第三方和外部接口，进入系统加入一层防腐层，千万别用第三方的实体bean去写自己项目的业务，千万别，千万别。这种依赖外部bean写业务的操作，接手的人深感绝望。
4.防腐层和第三方层也可以直接与service层交互。这里涉及胖领域和瘦领域的权衡了。个人偏向业务重就直接胖领域，没啥业务或跟本没有业务，瘦领域我也不要了，直接service层走你。这里的选择主要看当下业务情况和个人对将来的预期。
5.简单一定优雅，优雅不一定简单。k8s的容器编排很复杂，麻烦，但它的开放思想和架构抽象，真心让人惊叹。展开作者回复: 我理解你说的防腐层就是manager层，而我说的manager层也封装了数据访问层，提供原子的服务接口，而service层是对这些原子接口的编排，所以说尽量不要数据层打交道。
当然每个团队可能有更合适的分层方式 1 4
2019-10-11老师，我看阿里分层图中，service层是可以直接调用dao层的，manager层也是可以直接调用dao层的，这两种调用分别是针对什么情况的呢作者回复: 我理解简单的业务可以不抽取manager，直接调用dao
2
2019-09-24传统公司很多是分层部署的，比如保险和金融公司。service和dao部署在比较严密的网络区域，controller层部署在一个较宽松的网络区域，对外提供服务。等于在网络上增加了一个缓冲区，来保证服务的安全；而且可以通过单向网络规范层级调用，controller可以调用服务层，而服务层是不能调用web层的。作者回复: 是的
2 2
2019-09-21请问下老师用的什么工具画图？很漂亮作者回复: 是苹果自带的keynote
2
2019-09-20有人说传统的 MVC 是贫血模式，与之对立的是充血模式，边界划分衍生出 DDD ，优劣到底是哪一个，弄不清楚呐，老师的观点是什么？作者回复: 贫血模型把数据和行为区分开，层次上更清晰，但是呢不够面向对象，因为对象肯定是有数据和行为的
充血模型是把数据和行为混在一起，缺点是我就不知道业务逻辑是写在biz层还是领域模型里面。
我更倾向于贫血模型吧，因为我觉得大团队里面很难规范哪些放在领域模型里面，哪些放在biz层，所以干脆就都放在biz层就好了 3 2
2019-09-20mvc这种结构让太多的人觉得项目工程结构理所应当就是这样的，然后呢，一大堆的业务逻辑就随意的堆砌在了service中，对象啥的，只是单纯的数据传输作用，出现了用面向对象的语言，写面向过程的程序的普遍现象。按照领域驱动设计的思路，最重要的还要有领域模型层。当然manage层这种方案也是一种思路，但是我觉得，这种方式，还不够，必须有清晰的业务模型和合理的分层结构配合，才能更好的提现分层的作用。作者回复: 是的，分层的方式也是不断演进的
2 2
2019-12-22有一本书叫，大型网站实战与Java中间件实践，和老师课程里的知识异曲同工之妙。学习了作者回复: 相关领域的知识的确是大同小异～大厂的实践也基本类似～多学、多看、多练、多思，不久就会成为更好的你
1
2019-11-28老师，可以这样理解吗。manager放的都是单一功能的接口，service层去组装manager的接口，这样service层只需要注入manager层的接口就可以了，但是service层接口也会有复用的情况，相当于service还是要互相注入的作者回复: 是的
1
2019-09-30老师您好：
如果将数据访问层单独部署，一方面可以为后期服务运维降低成本，二来可以提高数据访问层的复用度（数据访问层对外提供API，其他层的应用通过API方式与数据库进行交互），三来可以屏蔽各个数据库实现的具体细节。作者回复: 嗯那 是一种更细粒度的拆分
1
2019-09-26比方说，单一职责原则规定每个类只有单一的功能
这个定义是对SRP的误解，原定义是：
SRP: 1. A module should be responsible to one, and only one, actor. 2. Separate the code that different actors depend on.
所以单一职责原则不是说每个类只有单一的功能，而是每个类最好只有一个被改变的原因。展开作者回复: SRP是一个类有单一的职责，是期望功能尽量内聚到一个类中。也许功能这个词儿不准确，不过思想是这样的。
1
2019-09-26感觉这种分层的思想大多是体现在业务系统中，但是像spring，dubbo之类的并不是按照这个去分层的作者回复: 也是有分层的，只是不像业务系统这样分为典型的三层架构
1- 2019-09-26老师你好，请问你说的业务逻辑放在manager，service来编排manager的原子服务，所谓的业务逻辑是指？manager的原子服务是指？如果这样处理的话，事务应该放在哪一层处理
作者回复: 业务逻辑就是你的产品逻辑，比如创建用户要做些啥。
manager层的原子服务指的是实现单一功能的服务。
事务应该是在service层 1 1 
2019-09-25文中的图用什么软件画的？方便告知一下么？编辑回复: 苹果自带的Keynote哦😜
1