前言

从之前文章了解到一个简单的订单系统订单数据只需要一张简单的订单表就能够搞定,但随着业务的发展,单表会变得会越来越臃肿,越来越不容易维护。此时我们就需要对订单进行分表操作(注意此处的分表仅仅是业务层面的分表,不涉及高并发)。来方便日后订单系统的迭代开发。与订单中心交互最多的自然是业务系统和支付系统。接下来这篇文章带你如何切割订单表结构。

意义

• 订单系统各种订单类型的流转，触发事件、执行事件如果不利用状态机代码会变得更加复杂且难以维护
• 通过状态机,能够把状态流转的概念抽象出来,更符合java编程思想的规范
• 状态机能够反映时序的布进控制

本系列文章从订单系统的演进,带你从0到1搭建订单系统,以及订单系统的迭代优化与支付系统和收银台系统的交互。完成从0搭建订单支付中心系统的设计。

前言

• 从事订单支付系统的设计研发已经接近俩年了,一直想好好把其中一些思考沉淀下来。一是回顾之前的设计,看看迭代过程中的一些思路是否合理,如果给自己从头再来的机会(不用考虑苦逼的兼容脏数据等等问题)能否设计得更好?二来自己一直想培养写博客的习惯,却从15年一直到现在都没有养成,希望从现在开始能坚持下来一步一步写下去(无论技术还是感悟),此系列文章算是个开头,希望这个开头不太难

张炎-3年-java

• 张炎/男/1994
• 手机：18390236566
• Email：18390236566@163.com
• QQ/微信号：578033593
• github：https://github.com/zhangyan1
• 博客：https://zhangyan1.github.io/
• 学历：湖南科技大学/计算机科学与技术专业

---

技术文章

• 订单系列文章(https://zhangyan1.github.io/2019/09/17/order/order/)
• springAop详解（https://zhangyan1.github.io/2019/04/17/aop/#more）

问题

1. 面向切面编程的理解?
   AOP的本质是在一系列纵向的控制流程中，把那些相同的子流程提取成一个横向的面

生产者消费者模式并不是JAVA23种设计模式之一，23种设计模式都是建立在面向对象的基础之上的，但其实面向过程的编程中也有很多高效的编程模式，生产者消费者模式便是其中之一，它是我们编程过程中最常用的一种设计模式

  有时候在较为复杂的查询中,会出现较为复杂的逻辑,直接写在sql当中一来不够明了,二来会令二次修改的时候变得尤为困难不利于维护,既然是搞java的,面相对象编程自然要学会封装,所以自定义function就出现了它的意义,可以让sql便于维护一目了然,能更加方便的处理较为复杂的关联查询逻辑等等好处

  从15年就计划开始写博客,来来回回折腾了很久，一直没有坚持下来,一直到现在可能博客数量还停留在csdn上那寥寥数篇,感觉是时候立个flag写写博客，把自己学习的知识好好整理一遍,也算是重新复习一遍。也是未来技术路上不断学习的记录。