2019-11-06微服务之间通过服务内部的应用层来连接多个微服务，微服务之间的相互调用；有两个疑问：1，微服务之间互相调用应该是什么样子？会不会就出现了网状微服务的调用关系结构了
2，是把这个夸多个微服务的应用层独立起来成为一个微服务（类似BFF微服务，没有领域）减少微服务之间调用关系？微服务之间就应该减少依赖调用？作者回复: 微服务之间要分两种情况，一种是项目级的少量微服务之间的调用。这样的调用可以放在微服务内的应用层，没必要再单独拿出一个微服务来进行服务组合和编排。
另外一种是复杂的企业级微服务调用和组合。拿出一个独立的BFF微服务的主要目的，一个是避免在一个微服务内组合太多的微服务的应用服务。二是，通过BFF微服务编排组合，可以减少由于前台的需求变化，传导到后端微服务中，可以降低后端微服务的发版频率，保持后端微服务的稳定。 4
2019-11-05关于这几种架构的区别，我觉得可以有一条原则作为主线，就是依赖倒置，不管是clean架构还是分层，或者六边形架构，都是高层次依赖于低层次的接口，都是为了实现关注点分离，提高代码的内聚性，隔离变化，最终达到稳定性的同时拥有良好的扩展性，架构最终都是趋同的，不同点就是他们在层与层之间的扩展点的方式不同。😄 4
2019-10-30想起了一句话：软件开发中遇到的所有问题，都可以通过增加一层抽象来解决。
对于依赖倒置的实现不是很清楚，按我的理解就是面向接口编程，由调用方将基础设施层的具体实现传入到被调用的服务，老师可以详细解释一下吗？作者回复: 是这样的。直白一点就是业务的归业务，基础的归基础，两者通过一层来适配，具体就是通过接口的方式。
2 3
2019-10-30分层架构、整洁架构、六边形架构有什么区别？作者回复: 它们几个其实是一点一点继承和发展过来的，在大的分层上基本上没什么太大的差异，思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。
1 3
2019-11-19请问老师，在设计微服务接口编排的时候，有哪些需要注意的地方？最好可以在github上给一个demo。作者回复: 你是说应用服务的编排吗？
你把这种编排理解成在同一个微服务内，一个方法对多个不同方法的调用就可以了，如果涉及到外部微服务的接口调用，你需要做DO与DTO的数据转换。 1 2
2019-11-13如果有了BFF这一层做统一编排，微服务内部还需要编排吗？如果碰到如下两种方案
A调用B， B再调用C
A调用B , A再调用C
刚开始识别不出复用性，两个方案感觉都可行，如何抉择，有什么原则指导吗？作者回复: BFF做微服务之间的编排。微服务内的应用服务主要做领域服务的编排和聚合之间的协调。BFF是微服务之间的，应用服务是微服务内的。
2- 2019-10-30看完后，就是没区别。
作者回复: 没有差异就不会有这么多叫法😄。它们几个其实是一点一点继承和发展过来的，在大的分层上基本上没什么太大的差异，思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。
1 
2019-10-30思考题：
面向用户的展现层可以快速响应外部需求进行调整和发布，灵活多变，
应用层通过服务组合和编排实现业务流程的快速适配上线，
领域层基本就不需要太多的变化了，
如果真的万不得已要修改领域层，领域层也要遵循面向对象的6大原则(单一职则原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则），保证领域层高内聚低耦合。作者回复: 是的，领域层也是少不了要演进的😄。
1 1
2019-10-30项目级微服务的那张图中，调用其他微服务的功能往往发生在领域层的领域服务中，甚至是领域模型的方法中，因为领域的某个属性或者能力依赖于其他服务，这种情况是设计的不合理导致的还是属于正常的呢？作者回复: 微服务之间的调用都是在应用层。
2 1
2019-10-30项目级微服务和企业级微服务的例子里，每个微服务都是有自己单独的注册中心？
我理解的是，一套微服务体系，包括：一个注册中心集群，微服务A集群，微服务B集群 等微服务集群，API网关集群。所有服务均通过API网关对外暴露，API网关还负责鉴权、限流、路由分发等。作者回复: 不是每个微服务都有自己的API网关，只是做一个示例。多个微服务可以共用一个API网关的。
在企业级中台设计的时候可以一个中台多个微服务共用一个网关。 1
2019-10-30回答问题：
1.为了支持外部应用，内部核心业务必须增加新逻辑。这种情况主要是要提高对价值的意识和风险的敏感。尽量不去加核心逻辑的代码，如果加了，必须是有足够价值的特性，且风险点可控或无。
2.为了支持外部应用，内部核心业务存在现有功能逻辑，但需调整兼容。这种情况就对该核心逻辑做进一步抽象，将通用部分复用，常变部分做抽象，实现更细力度的配置策略的定制能力。（当然也是要有足够价值）。
提问：
老的大项目并没有合理的架构分层。套到整洁架构上来看。
1.领域服务层会干领域模型的活。（贫血领域模型）
2.领域服务层会干应用层的活。（领域层大量rpc调用外部服务，并依托外部服务返回的dto做大量业务）
3.基础层会干领域服务的事。（dao层写业务，发mq，存solr，redis）
对于以上情况，做既有代码改善的小步重构，老师可有好套路或则思路？毕竟这种项目要大改规范，成本（时间）和风险（线上事故）都是接受不了的。（我重构了一遍，但是是业务架构上的。领域服务和基础层的职责越界并没有全量调整，仅是跟着需求，若涉及到就修修补补）展开作者回复: 这里你可以考虑单体架构的演进方式。可以先对系统做整体的领域建模分析，分解成多个不同的子域，建立领域模型。再根据优先级将部分领域模型对应的功能和数据从原来的单体应用中拆分出来，拆分为微服务。对原来的单体系统的前端提供API服务，原有系统的前端界面保持不变，整个架构演变用户无感知。当所有领域模型的微服务建设完成后，就可以抛弃原来的单体应用了。
1
2019-10-30【在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的】这种依赖倒置具体指的什么？是每个微服务不用配置自己的数据库，直接用数据仓库？数据库更换或者出问题了，自动切换配置屏蔽故障库？不太明白作者回复: 仓储模式是一种设计模式。它是在应用业务逻辑和数据层之间增加的一个抽象层，应用逻辑通过调用仓储接口的方式与数据层交互，与数据相关的实现都在仓储实现中实现，这样就可以避免在应用逻辑中混入数据相关的实现逻辑。从而就解耦了应用逻辑和数据逻辑。在基础资源变化时不会对应用逻辑有太大的影响。
2 1- 2019-10-30ddd分层、整洁架构、六变形架构。没看出太大的区别。核心都是应用层、领域层。 这三种架构的基础层，其它各层都可访问？
作者回复: 基础层是面向所有层的。
1 1 
2019-10-30DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦作者回复: 是这样的。
1
2020-01-02有个点一直不太理解，还望老师解惑。
文章提到抽象出一个仓储的接口，与基础层的数据库进行解耦，方便后续有替换数据库。这种情况在实际场景中很少出现，选用合适的存储中间件是一件重要的事情，一般在项目初期就确定了，中途替换的概率很小，为了这样的小概率事件，是不是有些过度设计？作者回复: 现在技术发展这么快，一切皆有可能的。这样做其实也是将领域模型和资源逻辑解耦的过程。
2020-01-02solid原则、kiss原则、遵循高类聚低耦合原则、oop的封装继承和多态、抽象、领域核心能力、ddd分层依赖倒置解耦、洋葱由外向内依赖、六边形适配、微服务编排（项目、企业中台BFF）、区分变化和不变，将变化封装和隔离，可以引入防腐层实现架构演进和过度。
2019-12-31之前在看《微服务设计》一书中，记得作者提到六边形架构比较适合DDD,提倡各微服务应用采用saga事件的方式降低服务间的依赖。作者回复: 其实这几种架构模式大同小异，saga是通过分布式事务来保证微服务之间的数据一致性。对于实时性要求不高的建议优先采用领域事件驱动机制。
2019-12-30请教个问题 看到的都是关于用户层主动调用服务的方式 那后端推送的形式也是这样的设计嘛？作者回复: 后端推送是指异步的事件机制吗？在领域事件那一节有专门介绍。
2019-12-29老师，如果分领域分库拆分了微服务，前台有一个聚合查询需求，这个聚合查询包含了有订单，商品，评论等领域的信息，对于这种横跨多领域的查询是需要采用搜索引擎还是其他的方法？
2019-12-29个人感觉项目级微服务这里有问题，服务a的应用层直接调用服务b的应用层，那如果服务b再调服务a应用层不就成环了。我觉得应该是应用层只能调取下层接口，服务a的应用层也只能调用服务b的领域层作者回复: 这种服务调用方式要尽量避免。在领域建模的时候，要根据服务地图和微服务的上下游关系把这种循环调用的方式切断。