工程师的首要技术使命就是控制复杂度，本项目结合COLA 4.0（整洁面向对象分层架构）实现。
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.0adapter 暂时用不到，就用 controller 代替了。
用户登录、注册、查询用户列表
重构项目时，可以先把模块下的包建好，然后把之前项目的代码迁到指定包。最后，按业务线连起来，调试、跑通。
实践的时候走了不少弯路，建议把作者写的 5 篇博客看一遍（链接放文末了）
可能有错，欢迎Issue，谢谢
- 不要把领域对象和数据库中的存的xxxDO混为一谈；想一下，领域对象要创建人、修改人、逻辑删除标识有啥用？
- 一开始不要过度设计，需求增加的过程中，更能看清项目未来的方向；另外，不要把重构一直往后拖，越早重构越可控；
- xxxDTO 什么时候用呢，DTO 是不是完全可以用 xxxCO、xxxVO 等代替？
含有部分个人习惯
| 规范 | 用途 | 解释 |
|---|---|---|
| xxxCO | Client Object | 客户对象，用于传输数据，等同于DTO |
| xxxCmd | Client Request | Cmd代表Command，表示一个写请求 |
| xxxQuery | Client Request | Query，表示一个读请求 |
| xxxCmdExe | Command Executor | 命令模式，每一个写请求对应一个执行器 |
| xxxQueryExe | Query Executor | 命令模式，每一个读请求对应一个执行器 |
| xxxVO | Value Object | 值对象 |
| xxxEntity | Entity | 领域实体 |
| xxxDO | Data Object | 数据对象，用于持久化 |
| xxxInterceptor | Command Interceptor | 拦截器，用于处理切面逻辑 |
| IxxxService | API Service | xxxServiceI 不太习惯，就把 I 放在前边吧 |
| xxxDomainService | Domain Service | 需要多个领域对象协作时，使用DomainService |
| xxxValidator | Validator | 校验器，用于校验的类 |
| xxxAssembler | Assembler | 组装器，组装外部服务调用参数 |
| xxxConvertor | Convertor | 转化器，实现不同层级对象互转（小彩蛋） |
| CRUD操作 | 方法名约定 |
|---|---|
| 新增 | create |
| 添加 | add |
| 删除 | remove（App和Domain层），delete（Infrastructure层） |
| 修改 | update |
| 查询（单个结果） | get |
| 查询（多个结果） | list |
| 分页查询 | page |
| 统计 | count |
没有银弹，仅做参考，按需取舍吧
要记住，留给公司一个方便维护、整洁优雅的代码库，是我们技术人员最高技术使命，也是我们对公司做出的最大技术贡献。
- 【日志规范】能用debug就不要用info，能用warn就不要用error。滥用的error与狼来了无疑；
- 【方法参数要少】参数越少，越容易理解，也便于测试，各个参数的组合就如笛卡尔积；
- 【空行规范】方法、逻辑分段，要加空行，提高代码可读性。车轮毂与车轴之间有空隙，车才能跑；书法绘画有留白；
- 【防止破窗】首先我们要有一套规范，并尽量遵守规范，不要做“打破第一扇窗”的人；其次，发现“破窗”要及时修复，不要让问题进一步恶化；
- 【三次原则】第一次用到某功能时，写一个特定的解决方法；第二次又用到时，复制上一次的代码；第三次出现时，就要着手写通用解决方案了；
- 【最小惊奇原则】写代码不是写侦探小说，要的是简单易懂，而不是时不时搞点烧脑的*操作；
- 【请求读写分离】增删改，会改变对象的状态，只需返回成功失败即可；查询是不会改变对象状态的，对系统没副作用。
-
张建飞著. 代码精进之路：从码农到工匠[M].北京：人民邮电出版社，2020.1