重庆百度推广seo,长春seo,网络公司哪个平台好,怎么做网站给国外看见很多同学不止一次和我反馈#xff0c;我们的系统很混乱#xff0c;主要表现在#xff1a;应用的层次结构混乱#xff1a;不知道应用应该如何分层、应该包含哪些组件、组件之间的关系是什么#xff1b;缺少规范的指导和约束#xff1a;新加一段业务逻辑不知道放在什么地方…很多同学不止一次和我反馈我们的系统很混乱主要表现在应用的层次结构混乱不知道应用应该如何分层、应该包含哪些组件、组件之间的关系是什么缺少规范的指导和约束新加一段业务逻辑不知道放在什么地方哪个类哪个包、应该起什么名字比较合适解决这些问题正是我创建COLAhttps://github.com/alibaba/COLA的初心之一——试图探索一套切实可行的应用架构规范这个规范不是高高在上的纸上谈兵而是可以复制、可以理解、可以落地、可以控制复杂性的指导和约束。自从COLA诞生以来我收到了很多的意见和建议。同时我自己在实践过程中也发现COLA 1.0的诸多不足有些设计是冗余的并不是很有必要而有些关键要素并没有囊括。譬如我最近在思考的应用架构核心和复杂业务代码治理就是对COLA 1.0的反思。结合实践中的探索和对复杂度治理持续的思考我决定对COLA进行一次全面的升级于是有了现在的COLA 2.0。从1.0到2.0不仅仅是数字的简单变化更是架构理念和设计理念的升级其主要变动点包括新架构分层Domain层不再直接依赖Infrastructure层。新组件划分对组件进行了重新定义和划分加了新组件去除了一些老组件ValidatorConvertor等。新扩展点设计引入了新概念让扩展更加灵活。新二方库定位二方库不仅仅是DTO也是Domain Model的轻量级表达和实现。新架构分层在COLA 1.0中我们的分层是如下图所示的经典分层结构在COLA 2.0中还是这些层次但是依赖关系发生了变化Domain层不再直接依赖Infrastructure层而是引入了一个Gateway的概念使用DIPDependency Inversion Principle依赖倒置反转了Domain层和Infrastructure层的依赖关系其关系如下图所示这样做的好处是Domain层会变得更加纯粹完全摆脱了对技术细节以及技术细节带来的复杂度的依赖只需要安心处理业务逻辑就好了。除此之外还有两个好处1. 并行开发只要在Domain和Infrastructure之间约定好接口可以有两个同学并行编写Domain和Infrastructure的代码。2. 可测试性没有任何依赖的Domain里面都是POJO的类单元测试将会变得非常方便也非常适合TDD的开发。新组件划分模块和组件的定义首先先明确一下组件Component这个概念的定义组件在Java中或者说在本文中其范围就是Java的包Package。还有一个词叫模块Module组件和模块这两个概念是比较容易发生混淆的。比如在《实现领域驱动设计》中作者就说If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.他认为Module是Package我认为这个定义容易造成混淆。特别是在使用Maven的时候在Maven中Module是一个Artifact通常是一个Jar而不是Package。比如COLA Framework就包括如下四个Modulemodulesmodulecola-common/modulemodulecola-core/modulemodulecola-extension/modulemodulecola-test/module /modules的确Module和Component这两个概念很相近很容易造成混淆。比如在StackOverflow上有一个提问【1】就是问Module和Component之间区别的。获得最高赞的答案是通过Scope来区分的。The terms are similar. I generally think of a module as being larger than a component. A component is a single part, usually relatively small in scope.这个回答和我的直觉反应是一致的即Module比Component要大。根据以上信息我在此对Module和Component进行一下定义说明在本文中都会遵照如下的定义和Notation表示法。模块Module和Maven中Module定义保持一致简单理解就是Jar。用正方体表示。组件Component和UML中的定义类似简单理解就是Package。用UML的组件图表示。一个Moudle通常是由多个Component组成的其关系和表示法如下图所示COLA 2.0的组件在COLA 2.0中我们重新设计了组件引入了一些新的组件也去除了一些旧组件。这些变动的宗旨是为了让应用结构更加清晰组件的职责更加明确从而更好的提供开发指导和约束。新的组件结构如下图所示这些组件各自都有自己的职责范围组件的职责是COLA的重要组成部分也就是我们上面说的“指导和约束”。这些组件的详细职责描述如下1、二方库里的组件api存放的是应用对外的接口。dto.domainmodel用来做数据传输的轻量级领域对象。dto.domainevent: 用来做数据传输的领域事件。2、Application里的组件service接口实现的facade没有业务逻辑可以包含对不同终端的adapter。eventhandler处理领域事件包括本域的和外域的。executor用来处理命令Command和查询Query对复杂业务可以包含Phase和Step。interceptor: COLA提供的对所有请求的AOP处理机制。3、Domain里的组件domain领域实体允许继承domainmodel。domainservice: 领域服务用来提供更粗粒度的领域能力。gateway对外依赖的网关接口包括存储、RPC、Search等。4、Infrastructure里的组件config配置信息相关。message消息处理相关。repository存储相关是gateway的特化主要用来做本域的数据CRUD操作。gateway对外依赖的网关接口Domain里的gateway的实现。在使用COLA的时候请尽量按照组件规范约束去构建我们的应用。这样可以让我们的应用结构清晰、有章可循。如此这般代码的可维护性和可理解性会得到极大的提升。新扩展点设计引入新概念在讨论之前我们先来明确一下在COLA2.0扩展设计中引入的新概念业务、用例、场景。业务Business就是一个自负盈亏的财务主体比如tmall、淘宝和零售通就是三个不同的业务。用例Use Case描述了用户和系统之间的互动每个用例提供了一个或多个场景。比如支付订单就是一个典型的用例。场景Scenario场景也被称为用例的实例Instance包括用例所有的可能情况正常的和异常的。比如对于“订单支付”这个用例就有“可以使用花呗”“支付宝余额不足”“银行账户余额不足”等多个场景。简单来说就是一个业务是有多个用例组成的一个用例是有多个场景组成的。用淘宝做一个简单示例业务、用例和场景的关系如下新扩展点的实现在COLA 2.0中扩展的实现机制没有变化主要变化就在于上文中引入的新概念。因为COLA 1.0的扩展设计思想来自于星环所以当初的扩展粒度也是copy了星环的“业务身份”。COLA 1.0的扩展定位的方法如下图所示然而在实际工作中能像星环那样支撑多个业务的场景并不常见。更多是对不用用例或是对同一个用例不同场景的差异化支持。比如“创建商品”和“更新商品”是两个用例但是大部分的业务代码是可以复用的只有一小部分需要差异化处理。为了支持这种更细粒度的扩展支持除了之前的“业务身份BizId”之外我还引入了Use Case和Scenario这两个概念。新的扩展定位如下图所示可以看到在新的扩展框架下原来只能支持到“业务身份”的扩展现在可以支持到“业务身份”“用例”“场景”的三级扩展无疑比以前要灵活的多并且在表达和可理解性上也比以前好。在新的扩展框架下例如我们实现上图中所展示的扩展在tmall这个业务下——的下单用例——的88VIP场景——的用户身份校验进行扩展我们只需要声明一个如下的扩展实现Extension就可以了。新二方库定位关于二方库的定位表面上来看是一个简单问题因为服务的二方库无外乎就是用来暴露接口和传递数据的DTO。不过往深层次思考它并不是一个简单的问题因为它涉及到不同界限上下文Bounded Context之间的协作问题。它是分布式环境下不同服务SOARPC微服务叫法不同本质一样之间如何协作的重要架构设计问题。Bounded Context之间的协作如何实现不同域之间的协作同时又要保证各自领域的概念的完整性是有一套方法论的。总体来说大概有两种方式共享内核Shared Kernel和防腐层ACLAnti-Corruption Layer。1. 共享内核Shared KernelIt’s possible that only one of the teams will maintain the code, build, and test for what is shared. A Shared Kernel is often very difficult to conceive in the first place, and difficult to maintain, because you must have open communication between teams and constant agreement on what constitutes the model to be shared.上面是引用《DDD Distilled》作者是Vaughn Vernon关于Shared Kernel描述的原话其优点是Share减少重复建设其缺点也是Share团队之间紧耦合。2. 防腐层ACLAnti-Corruption LayerAn Anticorruption Layer is the most defensive Context Mapping relationship, where the downstream team creates a translation layer between its Ubiquitous Language (model) and the Ubiquitous Language (model) that is upstream to it.同样是来自于《DDD Distilled》, 防腐层是隔离最彻底的做法其优点是没有Share完全解耦各自独立其缺点也是没有Share有一定的转换成本。不过我和Vernon的观点差不多都比较赞成防腐层的做法。因为增加的语义转换陈本相较于系统的可维护性和可理解性而言是完全值得的。Whenever possible, you should try to create an Anticorruption Layer between your downstream model and an upstream integration model, so that you can produce model concepts on your side of the integration that specifically fit your business needs and that keep you completely isolated from foreign concepts.二方库的重新定位在大部分情况下二方库的确是用来定义服务接口和数据协议的。但是二方库区别于JSON的地方是它不仅仅是协议它还是一个Java对象一个Jar包。既然是Java对象就意味着我们就有可能让DTO承载除了gettersetter之外的更多职能。这个问题以前没有引起我的重视但是最近在思考domain model的时候我发现我们是可以在让二方库承担更多职责的发挥更大的作用。实际上在阿里我发现有些团队已经在这么实践了而且我觉得效果还不错。比如中台的类目二方库在这个事情上就做了比较好的示范。类目是商品中比较复杂的逻辑里面涉及很多计算我们先看一下类目二方库的代码是怎么写的从上面的代码我们可以发现这已经远远超出DTO的范畴了这就是一个Domain Model有数据有行为有继承。这样做合适吗我认为是合适的首先DefaultStdCategoryDO用到的所有数据都是自恰的即这些计算是不需要借助外面的辅助自己就能完成。比如判断是否是根类目是否是叶子类目获取类目的名称路径等都是依靠自己就能完成。其次这就是一种共享内核我把自己领域的知识语言、数据和行为通过二方库暴露出去了假如有100个应用需要使用isRoot( )做判断你们都不需要自己实现了。什么不是说不推荐共享内核的做法吗好吧小孩子才分对错好吗。此处的共享内核我认为是有积极意义的特别是类目这种轻数据、重计算的场景。不过共享带来的紧耦合也的确是一个问题。所以如果我是类目服务的Consumer的话我会选择用一个Wrapper去对Category进行包装复用这样既可以复用它的领域能力又可以起到隔离防腐的作用。COLA中的二方库说到这里我想你应该已经理解我对二方库的态度了。是的二方库不应该仅仅是接口和DTO而是领域的重要组成部分是实现Shared Kernel的重要手段。因此我打算在COLA 2.0中扩大二方库的职责范围。主要包括两点二方库中的domain model也是领域的重要组成部分是“轻量级”的领域能力表达所谓“轻量级”是说表达是自恰和足够内聚的类似于上面说的StdCategoryDO的案例。当然能力的表达也需要遵循通用语言Ubiquitous Language。不同Bounded Context之间的协作要充分利用好二方库的桥梁作用。其协作方式如下图所示。注意这只是建议不是标准。实际上我们永远要在共享和耦合之间做一个权衡世界上没有完美的架构也没有完美的设计。 合不合适还需要你自己根据实际场景自己去定夺。COLA框架的扩展机制至此关于COLA 2.0的改动点我已经交代的差不多了。再追加一个彩蛋吧。泄密一下COLA作为一个框架Framework是如何支持扩展的。框架作为一个组件是被集成在系统中完成某一特定任务的比如logback作为一个日志框架是帮助我们解决打印日志、日志格式、日志存储等问题的。但面对各种应用场景框架本身没办法预测你想要的日志格式、日志归档的方式。这些地方需要一个扩展机制赋能用户自己去配置、去扩展。就扩展的实现方式而言一般有两种方式一种是基于接口的扩展一种是基于数据配置的扩展。基于接口的扩展基于接口的扩展主要是利用面向对象的多态机制先在框架中定义一个接口或者抽象方法和处理该接口的模板然后用户实现自己的定制。 其原理如下图所示这种扩展方式在框架中使用很广泛例如Spring中的ApplicationListener用户可以实现这个Listener来做容器初始化之后的特殊处理。再比如logback中的AppenderBase用户可以通过继承AppenderBase实现定制的Appender诉求往消息队列发送日志。COLA作为一个框架这样的扩展能力在所难免比如我们有一个ExceptionHandlerI在框架中我们提供了一个默认实现代码如下但是并不是每个应用都愿意这样的安排因此我们提供了扩展当用户提供了自己ExceptionHandlerI实现的时候优先使用用户的实现如果用户没有提供使用默认实现基于数据配置的扩展基于配置数据的扩展首先要约定一个数据格式然后通过利用用户提供的数据组装成实例对象用户提供的数据是对象中的属性有时候也可能是类比如slfj中的StaticLoggerBinder其原理如下图所示我们一般在应用中使用的KV配置都属于这种形式框架中的使用场景也很多比如上面提到的logback中对日志格式、日志大小的logback.xml配置。在COLA中我们通过Annotation对扩展点的配置Extension(bizId tmall, useCase placeOrder, scenario 88vip)也是一种典型的基于数据的配置扩展。如何使用COLA 2.0源代码COLA 2.0的源代码在 https://github.com/alibaba/COLA生成COLA应用COLA 2.0 提供了两套Archetype一套是纯后端应用另一套是Web后端应用他们的区别是Web后端应用比纯后端应用多了一个Controller模块其它都一样。Archetype的二方库我已经上传到Maven Repo了可以通过如下命令生成COLA应用生成纯后端应用没有Controllermvnarchetype:generate -DgroupIdcom.alibaba.demo -DartifactIddemo -Dversion1.0.0-SNAPSHOT-Dpackagecom.alibaba.demo-DarchetypeArtifactIdcola-framework-archetype-service-DarchetypeGroupIdcom.alibaba.cola -DarchetypeVersion2.1.0-SNAPSHOT生成Web后端应用有Controllermvn archetype:generate -DgroupIdcom.alibaba.demo -DartifactIddemo-Dversion1.0.0-SNAPSHOT -Dpackagecom.alibaba.demo-DarchetypeArtifactIdcola-framework-archetype-web-DarchetypeGroupIdcom.alibaba.cola -DarchetypeVersion2.1.0-SNAPSHOT我们假设新建的应用叫demo那么执行命令后会看到如下的模块结构上部分是应用骨架下部分是COLA框架。在生成的应用里面有一些demo的代码可以直接用mvn test进行测试。如果是Web后端应用可以运行TestApplication启动Spring Boot容器然后直接通过REST URL http://localhost:8080/customer?nameAlibaba 访问服务。COLA 2.0整体架构最后按照老规矩还是给两张全局的架构视图。以便你可以从全局上把握COLA。注意COLA有两层含义一层含义是作为框架的COLA主要提供一些应用中所需共用组件的支持。另一层含义是指COLA架构是指通过COLA Archetype生成的应用骨架的架构。这里所说的架构视图是应用架构视图。依赖视图调用视图