从业这么多年，接触过银行的应用，Apple的应用，eBay的应用和现在阿里的应用，虽然分属于不同的公司，使用了不同的架构，但有一个 共同点就是都很复杂 。导致复杂性的原因有很多，如果从架构的层面看，主要有两点，一个是架构设计过于复杂，层次太多能把人绕晕。另一个是根本就没架构，ServiceImpl作为上帝类包揽一切，一杆捅到DAO（就简单场景而言，这种 Transaction Script 也还凑合，至少实现上手都快。

这种人为的复杂性导致系统越来越臃肿，越来越难维护，酱缸的老代码发出一阵阵恶臭，新来的同学，往往要捂着鼻子抠几天甚至几个月，才能理清系统和业务脉络，然后又一头扎进各种bug fix，业务修补的恶性循环中，暗无天日！

CRM作为阿里最老的应用系统，自然也逃不过这样的宿命。不甘如此的我们开始反思到 底是什么造成了系统复杂性？ 我们到底能不能通过架构来治理这种复杂性？ 基于这个出发点，我们团队开始了一段非常有意义的架构重构之旅（Redefine the Arch），期间我们参考了SalesForce，TMF2.0，汇金和盒马的架构，从他们那里汲取了很多有价值的输入，再结合我们自己的思考 最终形成了我们自己现在的基于扩展点+元数据+CQRS+DDD的应用架构 。该架构的特点是可扩展性好，很好的贯彻了OO思想，有一套完整的规范标准，并采用了CQRS和领域建模技术，在很大程度上可以降低应用的复杂度。本文主要阐述了我们的思考过程和架构实现，希望能对在路上的你有所帮助。

复杂性来自哪里

分层不合理

复杂性应对之道

扩展点设计

public interface ContactConflictRuleExtPt extends RuleI, ExtensionPointI {
    * 查询联系人冲突
    * @param contact 冲突条件，不同业务会有不同的判断规则
    * @return 冲突结果
   public boolean queryContactConflict(ContactE contact);
2、实现业务的扩展实现
 
@Extension(bizCode = BizCode.ICBU)
public class IcbuContactConflictRuleExt implements ContactConflictRuleExtPt {
    @Autowired
    private RepeatCheckServiceI repeatCheckService;
    @Autowired
    private MemberMappingQueryTunnel memberMappingQueryTunnel;
    private Logger logger = LoggerFactory.getLogger(getClass());
     * 查询联系人冲突
     * @param contact 冲突条件，不同业务会有不同的判断规则
     * @return 冲突结果
    @Override
    public boolean queryContactConflict(ContactE contact) {
        Set<String> emails = contact.getEmail();
        //具体的业务逻辑
        return false;
3、在领域实体中调用扩展实现
 
@ToString
@Getter
@Setter
public class CustomerE extends Entity {
	 * 公司ID
	private String companyId;
	 * 公司(客户)名字
	private String companyName;
	 * 公司(客户)英文名字
	private String companyNameEn;
	 * 给客户添加联系人
	 * @param contact
	public void addContact(ContactE contact,boolean checkConflict){
		// 业务检查
		if (checkConflict) {
			ruleExecutor.execute(ContactConflictRuleExtPt.class, p -> p.queryContactConflict(contact));
		contact.setCustomerId(this.getId());
		contactRepository.create(contact);
在上面的代码中，框架在runtime的时候之所以可以找到对应的扩展实现，主要是靠@Extension(bizCode = BizCode.ICBU)这个Annotation, 因为在系统启动时，Bootstrap会扫描所有的扩展实现并注册并缓存到HashMap里面。
 
面向对象不仅是一种编程语言，更是一种思维模式。所以看到很多简历里面写“精通Java”，没写“精通OO”，也算是中肯，因为会Java语言并不代表你就掌握了面向对象思维（当然，精通Java也不是件易事），要想做到精通，必须要对OO设计原则，模式，方法论有很深入的理解，同时要具备非常好的业务理解力和抽象能力，才能说是精通，这种思维的训练是一个长期不断累积的过程，我也在路上，下面是我对面向对象设计的两点体会：
 
SOLID
 
SOLID是单一职责原则(SRP)，开闭原则(OCP)，里氏替换原则(LSP)，接口隔离原则(ISP)和依赖倒置原则(DIP)的缩写，原则是要比模式（Design Pattern）更基础更重要的指导准则，是面向对象设计的Bible。深入理解后，会极大的提升我们的OOD能力和代码质量。
 
比如我在开篇提到的ServiceImpl上帝类的例子，很明显就是违背了单一职责，你一个类把所有事情都做了，把不是你的功能也往自己身上揽，所以你的内聚性就会很差，内聚性差将导致代码很难被复用，不能复用，只能复制（Repeat Yourself），其结果就是一团乱麻。
 
 
再比如在java应用中使用logger框架有很多选择，什么log4j，logback，common logging等，每个logger的API和用法都稍有不同，有的需要用isLoggable()来进行预判断以便提高性能，有的则不需要。对于要切换不同的logger框架的情形，就更是头疼了，有可能要改动很多地方。产生这些不便的原因是我们直接依赖了logger框架，应用和框架的耦合性很高。
 
怎么破？ 遵循下依赖倒置原则就能很容易解决，依赖倒置就是你不要直接依赖我，你和我都同时依赖一个接口（所以有时候也叫面向接口的编程），这样我们之间就解耦了，依赖和被依赖方都可以自由改动了。
 
 在我们的框架设计中，这种对SOLID的遵循也是随处可见，Service Facade设计思想来自于单一职责SRP；扩展点设计符合关闭原则OCP；日志设计，以及Repository和Tunnel的交互就用到了依赖倒置DIP原则，这样的点还有很多，就不一一枚举了。当然了，SOLID不是OO的全部。抽象能力，设计模式，架构模式，UML，以及阅读优秀框架源码（我们的Command设计就是参考了Activiti的Command）也都很重要。只是SOLID更基础，更重要，所以我在这里重点拿出来讲一下，希望能得到大家的重视。
 
准确的说DDD不是一个架构，而是思想和方法论，关于如何领域建模的详细请参看我另一篇文章领域建模。所以在架构层面我们并没有强制约束要使用DDD，但对于像我们这样的复杂业务场景，我们强烈建议使用DDD代替事务脚本（TS: Transaction Script）。因为TS的贫血模式，里面只有数据结构，完全没有对象（数据+行为）的概念，这也是为什么我们叫它是面向过程的原因。
 
然而DDD是面向对象的，是一种知识丰富的设计（Knowledge Rich Design），怎么理解？，就是通过领域对象（Domain Object），领域语言（Ubiquitous Language）将核心的领域概念通过代码的形式表达出来，从而增加代码的可理解性。这里的领域核心不仅仅是业务里的“名词”，所有的业务活动和规则如同实体一样，都需要明确的表达出来。
 
业务语义显性化
 
例如前面典型代码图中所展示的，分配策略（DistributionPolicy）你把它隐藏在一堆业务逻辑中，没有人知道它是干什么的，也不会把它当成一个重要的领域概念去重视。但是你把它抽出来，凸显出来，给它一个合理的命名叫DistributionPolicy，后面的人一看就明白了，哦，这是一个分配策略，这样理解和使用起来就容易的多了，添加新的策略也更方便，不需要改原来的代码了。所以说好的代码不仅要让程序员能读懂，还要能让领域专家也能读懂。
 
再比如在CRM领域中，公海和私海是非常重要领域概念，是用来做领地划分的，每个销售人员只能销售私海（自己领地）内的客户，不能越界。但是在我们的代码中却没有这两个实体（Entity），也没有相应的语言和其对应，这就导致了领域专家描述的，和我们日常沟通的，以及我们模型和代码呈现的都是相互割裂的，没有关联性。这就给后面系统维护的同学造成了极大的困扰，因为所有关于公海私海的操作，都是散落着各处的repeat itself的逻辑代码，导致看不懂也没办法维护。
 
采用领域建模以后，我们在系统中定义了清晰的机会（Opportunity），公海（PublicSea）和私海（PrivateSea）的Entity，相应的行为和业务逻辑也被封装到对应的领域实体身上，让代码充分展现业务语义，让曾经散落在各处找到了业务代码找到了属于它们自己的家，它们应该在的地方。相信我，这种代码可读性的提升，会让后来接手系统的同学对你心怀感恩。下面就是我们重构后Opportunity实体的代码，即使你对CRM领域不了解，是不是也很容易看懂：
 
public class OpportunityE extends Entity{
	private String customerId;
	private String ownerId;
	private OpportunityType opportunityType;
    //是否可以捡入
	public boolean isCanPick(){
		return "y".equals(canPick) && opportunityStatus == OpportunityStatus.NEW || opportunityStatus == OpportunityStatus.ACTIVE;
    //是否可以开放
	public boolean isCanOpen(){
		return (opportunityStatus == OpportunityStatus.NEW || opportunityStatus == OpportunityStatus.ACTIVE)
			&& CommonUtils.isNotEmpty(ownerId);
    //捡入机会到私海
	public void pickupTo(PrivateSeaE privateSea){
		privateSea.addOpportunity(this);
    //开放到公海
	public void openTo(PublicSea publicSea){
		publicSea.addOpportunity(this);
    //机会转移
	public void transfer(PrivateSeaE from, PrivateSeaE to){
		from.removeOpportunity(this);//从一个私海移出
		to.addOpportunity(this);//添加到另一个私海中
如果整个系统都采用DDD，不仅代码的可读性和系统的可维护性会大大提升，系统之间的边界和交互也会更加的清晰。下图是CRM域的简要领域模型，基本上可以完整的表达CRM领域的核心概念
 




    
 
关于CQRS简要说一下，我们只使用了Command，Query分离的概念，我们提倡使用Domain Event，但是认为Event Sourcing是可选项。关于Command的实现我们使用了命令模式，因此以前的ServiceImpl的职责就只是一个Facade，所有的处理逻辑都在CommandExecutor里面。
 
这一块的设计比较直观，整个应用层划分为三个大的层次，分别是App层，Domain层和Infrastructure层。
 
App层主要负责获取输入，组装context，做输入校验，发送消息给领域层做业务处理，监听确认消息，如果需要的话使用MetaQ进行消息通知；
Domain层主要是通过领域服务（Domain Service），领域对象（Domain Object）的交互，对上层提供业务逻辑的处理，然后调用下层Repository做持久化处理；
Infrastructure层主要包含Repository，Config，Common和message，Repository负责数据的CRUD操作，这里我们借用了盒马的数据通道（Tunnel）的概念，通过Tunnel的抽象概念来屏蔽具体的数据来源，来源可以是MySQL，NoSql，Search，甚至是HSF等；Config负责应用的配置；Common是一写工具类；负责message通信的也应该放在这一层。
 
 这里需要注意的是从其他系统获取的数据是有界上下文（Bounded Context）下的数据，为了弥合Bounded Context下的语义Gap，通常有两种方式，一个是用大领域（Big Domain）把两边的差异都合起来，另一个是增加防腐层（Anticorruption Layer）做转换。什么是Bounded Context？ 简单阐述一下，就是我们的领域概念是有作用范围的（Context）的，例如摇头这个动作，在中国的Context下表示NO，但是在印度的Context下却是YES。
 
整洁的代码就像开篇提到的收纳整洁的玩具柜，和玩具收纳一样，需要做到以下两点：
 
东西不要乱放，我们的每一个组件（Module），每一个包（Package）都有明确的职责定义和范围，不可以放错，例如extension包就只是用来放扩展实现的，不允许放其他东西，而Interceptor包就只是放拦截器的，validator包就只是放校验器的。我们的主要组件如下图：
 
 组件里面的Package如下图：
 
 
东西放在合适位置后还要贴上合适的标签，也就是要按照规范合理命名，例如我们架构里面和数据有关的Object，主要有Client Object，Domain Object和Data Object，Client Object是放在二方库中和外部交互使用的DTO，其命名必须以CO结尾，相应的Data Object主要是持久层使用的，命名必须以DO结尾。
 
这个类名应该是自明的（self-evident)，也就是看到类名就知道里面是干了什么事，这也就反向要求我们的类也必须是单一职责的（Single Responsibility）的，如果你做的事情不单纯，自然也就很难自明了。如果我们Class Name是自明的，Package Name是自明的，Module Name也是自明的，那么我们整个应用系统就会很容易被理解，看起来就会很舒服，维护效率会提高很多。除了组件和包的命名规范以外，我们对类、方法名和错误码等都做了相关规定。
 
方法名约定
 
从某种意义上来说，任何的业务操作，落到数据的层面，都是对数据的CRUD（增删改查），因此在写业务代码的时候，会经常碰到关于CRUD的命名，就拿查询来说，fetch, retrieve, get, find, query等等都能表示查询的意思，为了命名的一致性和统一性，为了保证每个概念对应一个词，我们有必要对CRUD的命名做一个约定。
 
比如，在SOFA框架中，我们就对CRUD的命名做了如下约定：
 
CRUD操作
方法名约定
新增
create
添加
add
删除
remove（App和Domain层），delete（Infrastructure层）
修改
update
查询（返回单个结果）
get
查询（返回多个结果）
list
分页查询
page
统计
count
业务命名最好不用直接用CRUD，除非其行为有非常强的CRUD语义，比如用addContact表示添加联系人，removeContact表示删除联系人是可以接受的。但是如果你用createOrder和deleteOrder来表示下单和取消订单是不合适的，在业务层，更贴切的命名应该是placeOrder和cancelOrder。
 
当然在Infrastructure层，比如OrderDAO，你还是应该采用CRUD的命名方式，用createOrder和deleteOrder来表示对订单数据的创建和删除。
 
Tips：在业务层，尽量避免CRUD，努力找到更好的业务词汇来表达业务语义，如果非用不可，请使用约定好的CRUD命名。
 
错误码约定
 
异常主要分为系统异常和业务异常，系统异常是指不可预期的系统错误，如网络连接，服务调用超时等，是可以retry的；而业务异常是指有明确业务语义的错误，再细分的话，又可以分为参数异常和业务逻辑异常，参数异常是指用户过来的请求不准确，逻辑异常是指不满足系统约束，比如客户已存在。业务异常是不需要retry的。
 
我们的错误码主要有3部分组成：类型+场景+自定义标识
 
错误类型
错误码约定
举例
参数异常
P_XX_XX
P_CAMPAIGN_NameNotNull: 运营活动名不能为空
业务异常
B_XX_XX
B_CAMPAIGN_NameAlreadyExist: 运营活动名已存在
系统异常
S_XX_ERROR
S_DATABASE_ERROR: 数据库错误
Domain Event约定
 
Domain Event(领域事件)，是领域实体发生状态变化后，向外界publish出来的事件。
 该事件既可以在当前的Bounded Context下面被消费，也可以被其它Bounded Context消费。
 
其命名规则是：领域名称+动词的一般过去式+Event
 
这里的动词的一般过去式，非常关键，因为在语义上表达的是发生过的事情，因为Event总是在动作发生后再发出的。下面是几个举例：
 
CustomerCreatedEvent,表示客户创建后发出的领域事件。
OpportunityTransferedEvent，表示机会转移后发出的领域事件。
LeadsCreatedEvent，表示线索创建后发出的领域事件。
 
从开发的视角来看，主要是两方面的测试，一个是单元测试，一个是基于command的集成测试。
 
单元测试，主要是针对Domain层的业务逻辑测试，有下面3个约定：
 
测试粒度要小，通常是业务方法，其scope不要超过一个类。
要稳定，要快，使用mock，不要对外部环境有依赖。
放在Domain的test里面，命名方式为Entity + Test，例如CustomerTest, ContactTest, OpportunityTest等
 
@RunWith(MockitoJUnitRunner.class)
public class CustomerTest {
    @InjectMocks
    private IcbuCustomerE customerE = new IcbuCustomerE();
    @Mock
    private CustomerSearchTunnel customerSearchTunnel;
    @Test
    public void testIsCustomerAailableForPrivateSea(){
        //没有业务员
        PvgContext.set("","","","");
        Assert.assertFalse(customerE.isAvailableForPrivateSea());
        //是"删除客户"落入公海
        PvgContext.set("121212","","","");
        customerE.setCustomerGroup(CustomerGroup.AliCrmCustomerGroup.CANCEL_GROUP);
        Assert.assertFalse(customerE.isAvailableForPrivateSea());
        //可以捡入私海
        PvgContext.set("121212","","","");
        customerE.setCustomerGroup(CustomerGroup.AliCrmCustomerGroup.ENQUIRY_GROUP);
        Assert.assertTrue(customerE.isAvailableForPrivateSea());
集成测试，主要是针对Command的业务流程测试，有下面两个约定：
 
每个Command，以及分支场景必须要有集成测试覆盖。
不需要mock，依赖日常环境。
放在start的test里面，命名方式为XXXCmd + Test，例如IcbuLeadsAddCmdTest,CustomerPickupCmdTest等
 
public class IcbuLeadsAddCmdTest {
    @Autowired
    protected LeadsRepository leadsRepository;
    @Autowired
    private CommandBusI commandBus;
    @Test
    public void testLeadsExistWithNoCustomer(){
        //1. Prepare
        IcbuLeadsAddCmd cmd = getIcbuIMLeadsAddCmd();
        String tenantId = "cn_center_10002404";
        LeadsE leadsE = leadsRepository.getLeads(tenantId, cmd.getContactId());
        if(leadsE != null) {
            leadsE.setCustomerId(null);
            leadsRepository.updateCustomerId(leadsE);
        //2. Execute
        commandBus.send(cmd);
        //3. Check
        leadsE = leadsRepository.getLeads(tenantId, cmd.getContactId());
        Assert.assertEquals(leadsE.getCustomerId(), "179001");
COLA应用架构
 
经过上面的长篇大论，我希望我把我们的架构理念阐述清楚了，最后再从整体上看下我们的架构吧。我讲这个架构命名为COLA，全称是Clean Object-oriented and Layered Architecture，是一个整洁的，面向对象的，分层的，可扩展的应用架构，可以帮助降低复杂应用场景的系统熵值，提升系统开发和运维效率。
 
 目前COLA框架已经开源，要阅读源码或直接在项目中使用COLA，请移步：https://github.com/alibaba/COLA
 
##整体架构
 我们的架构原则很简单，即在高内聚，低耦合，可扩展，易理解大的指导思想下，尽可能的贯彻OO的设计思想和原则。我们最终形成的架构是集成了扩展点+元数据+CQRS+DDD的思想，关于元数据前面没怎么提到，这里稍微说一下，对于字段扩展，简单一点的解决方案就是预留扩展字段，复杂一点的就是使用元数据引擎。使用元数据的好处是不仅能支持字段扩展，还提供了丰富的字段描述，等于是为以后的SaaS化配置提供了可能性，所以我们选择了使用元数据引擎。和DDD一样，元数据也是可选的，如果对没有字段扩展的需求，就不要用。最后的整体架构图如下：
 
 
Archetype
 
因为框架包含了5个Module，20+的Package，如果手动创建的话很费时，而且很容易出错，所以创建了这个Archetype，可以一键构建框架的所有Artifacts，使用时，只需要将下面的命令中的demo替换成自己应用的名字即可：
 
mvn archetype:generate  -DgroupId=com.alibaba.crm -DartifactId=demo -Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.crm.demo -DarchetypeArtifactId=sofa-framework-archetype -DarchetypeGroupId=com.alibaba.sofa -DarchetypeVersion=1.0.0-SNAPSHOT
不管你是不是TDD吧，写几行代码，然后本地跑下测试验证一下总是个不错的习惯。因为代码还是热的，出错也容易定位。
 
但是本地启动PandoraBoot可不是个省心的事，我这台2.3G双核平均也要4分钟，严重的影响了效率。所以开发了这个工具，就是等PandoraBoot启动后，将线程Hold住，然后通过Console控制台输入要测试的方法或者类。使用这个工具很简单：
 
依赖COLA框架
使用TestApplication启动应用
 
public class TestApplication {
    public static void main(String[] args) {
        PandoraBootstrap.run(args);
        SpringApplication.run(Application.class, args);
        TestsContainer.start();//启动测试容器，避免重复启动PandoraBoot
工程师的首要技术使命就是控制复杂度，本项目结合COLA 4.0（整洁面向对象分层架构）实现。
使用 Maven archetype 创建项目
mvn archetype:generate  -DgroupId=com.amos -DartifactId=think -Dversion=1.0.0-SNAPSHOT -Dpackage=com.amos.think -DarchetypeArtifactId=cola-framework-archetype-web -DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=4.0.0
项目架构图
adapter 暂时用不到，就用 controller 代替了。
用户注册、登录、修改、查询用户 && 用户列表；
数据库采用内存数据库h2database，也即无需准备数据库
                                    前几天和几个饿了么的同学聊天，一听说他们还在使用COLA 1.0，我二话没说，90度鞠躬，赔礼道歉，虚心聆听他们的吐槽。COLA的初衷旨在控制复杂度，救码农于水火，惭愧的是，早期的思想不成熟，设计也多有缺陷，不仅没帮到他们，反而坑了他们，实在抱歉。
实际上，我在COLA 3.0迭代的时候，已经举起奥卡姆剃刀，砍掉了很多东西。
然而还不够，主要体现在对架构的思考还不够透彻。因此，经过仔细反思，有了这一版最新的COLA 4.0，期望回归初心，让COLA真正成为应用架构的最佳实践，帮助广大的业务技术同学，脱离酱缸
互联网业务迭代快，工期紧，导致代码结构混乱，几乎没有代码注释和文档。
互联网人员变动频繁，很容易接手别人的老项目，新人根本没时间吃透代码结构，紧迫的工期又只能让屎山越堆越大。
多人一起开发，每个人的编码习惯不同，工具类代码各用个的，业务命名也经常冲突，影响效率。
大部分团队几乎没有时间做代码重构，任由代码腐烂。
每当我们新启动一个代码仓库，都是信心满满，结构整洁。但是时间越往后，代码就变得腐败不.
                                    COLA 是 Clean Object-Oriented and Layered Architecture的缩写，代表“整洁面向对象分层架构”，是来自阿里技术专家的开源项目。目前COLA已经发展到COLA 4.0。
COLA既是架构，也是框架。COLA框架继承了DDD的设计思想。
COLA 开源地址：https://github.com/alibaba/COLA
一、为什么说COLA是架构？
在架构设计上，COLA主张像六边形架构那样，使用端口-适配器去解耦技术细节；主张像洋葱架构那样，以领域.
                                    最近，阿里云的同学告诉我，COLA作为应用架构，已经被选入阿里云的Java应用初始化的应用架构选项之一。
This is really something，于是，在这个里程碑节点上，我开始回过头来，重新审视COLA一路走来的得与失。
COLA作为一种架构思想无疑是成功的。但是作为框架，个人感觉有点鸡肋之嫌。 特别是在简洁性上做的不好，感觉做了不少画蛇添足的事情。
试想一下，有些功能我作为作者都很少去使用，我实在想不到，它为什么还有存在的理由。
基于上面的思考，我做了这一次COLA 2.0 到 COLA 3
Cola扩展点使用
Cola中提供了一种扩展点的机制，允许我们通过bizId（组织ID）、useCase（使用案例）、scenario（业务场景）三者动态的去选择实现类。有点类似与我们的策略模式，在程序运行的过程中，动态的选择实现类去处理我们的请求。
我就不多做解释了，下面的例子看了，就能明白这个扩展点怎么用了。
1、定义扩展点接口，实现ExtensionPointI
public interface Organiz.
                                    花名:神帅，毕业5年,混迹于大小厂打怪刷实战经验。资深Java开发工程师。
在企业服务领域和电商领域均有积累,最近一直在研究DDD和低代码领域,对后端微服务业务平台架构的实践和发展比较感兴...
                                    DDD作为一种优秀的设计思想，的确为复杂业务治理带来了曙光。然而因为DDD本身难以掌握，很容易造成DDD从理论到工程落地之间出现巨大的鸿沟。就像电影里面的桥段，只谈DDD理论姿势很优美，一...
应用的层次结构混乱：不知道应用应该如何分层、应该包含哪些组件、组件之间的关系是什么；
缺少规范的指导和约束：新加一段业务逻辑不知道放在什么地方（哪个类，哪个包）、应该起什么名字比较合适？
解决这些问题，正是我创建COLA的初心之一——试图探索一套切实可行的应用架构规范，这个规范不是高高在上的纸上谈兵，而是可以复制、可以理解、可以落地、可...
整洁面向对象分层架构。既是架构也是框架。
作为框架：
提供了扩展点功能组件和一般API定义规范组件。maven引入两个依赖：cola-core、cola-common。
cola应用架构：
App层主要负责获取输入，组装context，做输入校验，发送消息给领域层做业务处理，监听确认消息，如果需要的话使用MetaQ进行消息通知；
Domain层主要是通过领域服务（Domain Service），领域对象（Domain Object）的交互，对上层提供业务逻辑的处理，然后调用下层Reposi
二、COLA介绍
COLA 是 Clean Object-Oriented and Layered Architecture的缩写，代表“整洁面向对象分层架构”。目前COLA已经发展到COLA4.0
COLA分为两个部分，COLA架构和COLA组件。
三、COLA演变
1、COLA1.0
2、COLA2.0
2.0作了一个对于cola来说非常核心的改动，就是采用DIP的设计理念，这
                                    赠送jar包：mybatis-plus-extension-3.5.1.jar；
赠送原API文档：mybatis-plus-extension-3.5.1-javadoc.jar；
赠送源代码：mybatis-plus-extension-3.5.1-sources.jar；
赠送Maven依赖信息文件：mybatis-plus-extension-3.5.1.pom；
包含翻译后的API文档：mybatis-plus-extension-3.5.1-javadoc-API文档-中文(简体)-英语-对照版.zip；
Maven坐标：com.baomidou:mybatis-plus-extension:3.5.1；
标签：extension、baomidou、mybatis、jar包、java、中英对照文档；
使用方法：解压翻译后的API文档，用浏览器打开“index.html”文件，即可纵览文档内容。
人性化翻译，文档中的代码和结构保持不变，注释和说明精准翻译，请放心使用。
双语对照，边学技术、边学英语。
                                    赠送jar包：sentinel-datasource-extension-1.8.0.jar；
赠送原API文档：sentinel-datasource-extension-1.8.0-javadoc.jar；
赠送源代码：sentinel-datasource-extension-1.8.0-sources.jar；
赠送Maven依赖信息文件：sentinel-datasource-extension-1.8.0.pom；
包含翻译后的API文档：sentinel-datasource-extension-1.8.0-javadoc-API文档-中文(简体)-英语-对照版.zip；
Maven坐标：com.alibaba.csp:sentinel-datasource-extension:1.8.0；
标签：alibaba、csp、sentinel、extension、datasource、jar包、java、中英对照文档；
使用方法：解压翻译后的API文档，用浏览器打开“index.html”文件，即可纵览文档内容。
人性化翻译，文档中的代码和结构保持不变，注释和说明精准翻译，请
定义扩展点接口，类型可以是校验器，转换器，实体； 必须以ExtPt结尾，表示一个扩展点。
比如，我定义一个云枢的组织结构的扩展点接口，消息发送扩展点，二开扩展点，webapi的rest接口扩展点点。
定义扩展点接口
package com.authine.web.cola.domain.customer;
import com.alibaba.cola.extension.ExtensionPointI;
                                    Cola框架学习
偶然了解到cola这个框架（也是架构），接触到了DDD的思想， 为了理解代码，搜阅了很多文章，发现没有一篇能讲的通彻的，因为其中其实牵扯到很多知识，所以将各个方面的内容做了一个汇总，方便学习。
所引用文章路径已经标明，如有侵权，还请联系作者删除
采集参考文章：
领域驱动架构（DDD）建模中的模型到底是什么
领域驱动设计系列 (六)：CQRS
复杂度应对之道 - COLA应用架构
应用架构COLA 2.0
应用架构之道：分离业务逻辑和技术细节
对于单表模式的反思
单表功能做多了最容易犯错的地
                                    阿里妹导读：作者张建飞是阿里巴巴高级技术专家，入司6年，他创建了COLA。希望可以探索一套切实可行的应用架构规范，这个规范不是高高在上的纸上谈兵，而是可以复制、可以理解、可以落地、可以控...
&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&amp;gt;
&amp;lt;c3p0-config&amp;gt;
    &amp;lt;default-config&amp;gt;
        &amp;lt;property name=&quot;driverClass&quot;&amp;g