代码拉取完成，页面将自动刷新
什么样的项目是一个好的项目,如何做好一个项目？这个问题我考虑过很久，由于之前一直做项目外包，也接触到的了比较多的项目，但是我却从没有感觉到哪一个项目可以让自己感到非常满意，当然做好项目不仅仅单是技术层面的考虑，还需要考虑到与客户的配合、功能的梳理、团队的配合、公司的考核晋升体系等等一系列的问题，我们今天先只从技术层面出发来考虑如何做好一个后端项目。
在我慢慢看清楚领域模型之后，才有了些体会。先说一下我对领域模型的认识:领域模型实际上就是尽可能的引用类去解决问题，而不是函数，也就是朝着面向对象的方向看齐。这样做当然是对的，但却引发了一个新的问题就是如何划分类与类的职责？实际上划分职责的过程就是领域设计的过程。 下面是我对软件系统的认识:颗粒度越大(函数方法代码量越多)，功能调整的可能性就会越大，出现BUG的可能性也会越大，要时刻想尽一切办法去减小颗粒度，减小颗粒度不是让把100行的方法改成两个50行的方法，而是要用类去解决问题，这也将会驱使你不断进步。
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
业务对象模型（也叫领域模型domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。
领域模型、贫血模型、充血模型概念总结
复杂业务代码要怎么写
分离业务逻辑和技术细节
敏捷开发的关键是：阶段性发布可用功能版本，长期持续的推进项目进度。其实是比较好理解的，但是如何才能确保做好呢？实际上很多项目的研发过程就像是在垒扑克牌，一对一对的垒，越垒越高，在垒到足够高的时候，去调整一个小功能时却导致了整盘的倒塌，敏捷并不是把控好项目的根本，敏捷推进项目的一种方式。
/\
/\/\ /\
/\/\/\ /\ /\/\
/\/\/\/\ /\/\ /\/\/\
/\/\/\/\/\ /\/\/\ /\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
要时刻提醒自己: 看清目标,掌握好方向。
有了目标和方向了，你还不知从何下手？
首先要先摆脱函数式编程，开始拥抱面向对象，要准守规范与原则，拒绝CV战士。为什么这样呢？若不懂的话请先看下领域模型、贫血模型、充血模型概念总结 ，若还不懂，却依旧渴望真理的话，那请提交issue留言，我可以专门做个视频讲讲为什么。
本项目依赖COLA，运行本项目前需要先将COLA安装到本地。源码维护见: https://github.com/1991wangliang/COLA
层次介绍:
| 层次 | 说明 |
|---|---|
| controller | 提供服务的访问层，目前采用RestController的方式，也做基础数据格式校验的业务。 |
| service | 对应上图中的services部分，主要做4类事情:1、开启事务与事务消息，2、适配并调用Executor层，3、业务拓展，4、多个Executor的编排组装。 |
| convertor | 适配层，适配层的存在也是为了避免各层次间的强依赖,为了更清新的划分清楚层次，如command对象将不直接依赖vo对象，而是通过convertor或构造数据做适配 |
| executor | 具体业务命令的逻辑编排与执行，这是业务逻辑处理的关键地方,遵循CQRS分为Command与Query，executor是资源层的操控者。 |
| extension | 业务扩展层，可扩展多种业务实现，COLA提供了全局的策略规范。extension会在service层被调用 |
| domain | 洋葱图的核心部分:领域层，domain领域可细分为model与service(action) |
| event | event在架构图中属于资源层，event作为解耦系统的耦合度起到了非常关键的作用，同时也为解决事务问题提供了标准 |
| pojo | 数据dto对象，分为command/vo/co/ao... 等不同的dto对象 |
| repository | 资源层相对来说比较广泛，最基本的是对db的操作，对其他模块的操作(feign)，对搜索引擎或消息队列的操作都属于资源。可细分为:feign、db、search、message |
本项目功能:把大象放进冰箱，本项目的代码是我刚开始上路的起步阶段，还有很多不足，大家仅做参考。各层次的详细介绍可参考每一层中的package-info.java下的内容。
我对领域的理解从刚开始的探索，到慢慢在实际项目中使用有经历了一段时间。COLA框架实际上融合了很多东西，落地项目需要从这几步开始。
划分业务线的原理:
四色建模法会帮助我们梳理出来业务的关键时刻，这些是系统的核心业务，我们也直接将根据四色建模法来定义领域对象。但是在实际项目开发过程中，我们还会在做一步:“划分业务线”。这也是非常重要的一步，他将影响到业务的实现方式。
划分业务线是为了梳理业务功能。executor作为业务的编排逻辑，在处理业务的时候需要明确其边界。一个系统中的业务，可以分为三大类:核心业务、延伸业务、基础数据业务。举例来说一个交易的商城业务中，通常会将订单业务作为核心业务，订单触发的物流派单业务属于延伸业务，订单中商品及用户数据的维护称为基础数据业务，当然一个系统中可以存在多个核心业务。
划分业务类型的主要意义是为了解耦业务线，这里通常是采用事件的方式来解耦，例如订单完成以后将发送一个订单完成事件来触发订单后面的业务，在这里订单逻辑与延伸业务是不在一块执行的。这样做可以开发起来更简单明确同时也提供了更好的业务拓展能力。
Executor的注意事项:
关于单元测试的建议:
首先可参考COLA MOCK的方式来实现单元测试业务。我们实际采用的方式则是分开来测试，区分资源测试与逻辑测试。逻辑测试是只针对Executor层做单元测试，Executor层是业务的编排逻辑，对Executor测试可直接覆盖业务，
当然由于Executor层也引用了资源，对资源的引用时可直接采用mock的方式来处理，具体细节可参考demo下的单元测试代码。若需要对资源层做测试则直接跑资源层的测试代码即可，我觉得这个比较简单大多都是SQL层面的测试，然后再加一个全局事务回滚即可，这里的测试只关系资源不关心业务。
总之我们将测试分开来做分为资源测试与逻辑测试。针对代码的覆盖率检查可通过jacoco插件查看。
给大家的建议:
谈谈落地后的优势:
参考:
四色建模
CQRS
读写分离到CQRS
领域驱动设计DDD和CQRS落地
代码精进之路 从码农到工匠
开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。
这里的软件实体包括以下几个部分：
项目中划分出的模块
类与接口
方法
开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
开闭原则的作用
开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。
里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。
里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
里氏替换原则的作用
里氏替换原则的主要作用如下。
依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C.Martin）于 1996 年在 C++ Report 上发表的文章。
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
依赖、倒置原则的作用
依赖倒置原则的主要作用如下。
单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
单一职责原则的优点
接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。
迪米特法则的优点
迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
合成复用原则的重要性
通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
-------------------------------------希望这是一条你编程之路上的分界线--------------------------------------------
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。