关于软件设计的思考

友人 10:35:06
开了这么久的源码，有什么感悟？
老碗鱼 10:35:36
慢慢学会了怎么组织代码
友人 10:36:55
好比？
老碗鱼 10:37:27
之前写代码面向对象留的接口以为对不上
老碗鱼 10:37:37
组织的很差
老碗鱼 10:37:43
如今看了组织性更强
友人 10:39:02
呵呵，都没有专门写过抽象接口
老碗鱼 10:39:49
其实优秀的代码是一层一层写的
老碗鱼 10:40:00
看过画画的吧
友人 10:40:16
什么画画
老碗鱼 10:40:28
就是画家做画
老碗鱼 10:40:45
他上去首先是描绘轮廓
老碗鱼 10:41:04
而后逐级实现
友人 10:42:57
可是这要求对框架有总体的认识
老碗鱼 10:43:56
你对业务熟悉
老碗鱼 10:44:13
并且对语言的组织性了如指掌
老碗鱼 10:46:03
好比，我看了一些源码以后，在工做项目中就发现一些架构的问题
友人 10:46:14
这么吊
友人 10:46:24
什么架构问题
老碗鱼 10:46:34
而后总结一个思路
老碗鱼 10:47:12
举个例子
老碗鱼 10:48:54
一张工程表
老碗鱼 10:49:25
他会有基本属性，还会有附加属性
老碗鱼 10:49:41
一般你会怎么建立这个表呢 ？
友人 10:50:04
两张或者三张
友人 10:50:21
要看附属性是随机的仍是固定的
老碗鱼 10:50:54
一般都是一个基本信息表
老碗鱼 10:51:21
而后几张附加信息表，而后里面都有一个字段是基本信息表的主键对吧
友人 10:52:00
是的
老碗鱼 10:52:31
项目在初期的时候这些表之间的关系很容易理清楚
老碗鱼 10:53:03
我加一个项目，要把基本信息和附加信息都提交上去，而后作个事务对吧
友人 10:53:48
嗯
友人 10:53:57
而后呢

 老碗鱼 10:54:19
一般项目无非也就是增删改查，只不过对于工程来讲，是须要添加基本信息和附加信息这几个方面
老碗鱼 10:54:42
可是理论上和单表的增删改查无异
老碗鱼 10:55:21
多的只有事务处理
友人 10:55:49
这个架构有什么问题
老碗鱼 10:56:03
问题问得好
老碗鱼 10:56:13
那么问题来了
友人 10:56:27

老碗鱼 10:56:46
等项目愈来愈大，绑定在基本信息的附加表也愈来愈多
老碗鱼 10:57:06
那么他们之间的关系就愈来愈淡漠
老碗鱼 10:57:47
好比我要添加一个附件，这个附件须要和好几个附件相关联
友人 10:58:09
是呀
老碗鱼 10:58:12
在项目后期，是没法控制多个表关联的增删改查的
友人 10:58:35
一个事务套进去喽
老碗鱼 10:58:50
由于你不知道我这个表的增删改查，会在那几张表上作出改变
友人 10:59:36
咱们如今的项目就是这样滴
老碗鱼 11:00:03
咱们把基本信息和附加信息统称为一个主体
老碗鱼 11:00:26
加入这个主体与另外一个主体之间发生关联
老碗鱼 11:01:01
若是我要删掉这个主体的信息，是否会影响到其余主体
老碗鱼 11:01:26
在项目逐渐扩大的时候，没人能所有控制得住
友人 11:01:58
因此就拆成小项目
老碗鱼 11:02:52
这个方案怎么解决？
老碗鱼 11:03:00
你说说看
友人 11:03:37
拆成小项目，各执行各的那部分
友人 11:04:27

老碗鱼 11:05:55
项目之间的关联度变大呢
老碗鱼 11:06:37
分布式是个好东西
友人 11:07:26
不是分布式，是把一个大业务，拆成小的。
老碗鱼 11:07:32
可是只从分开部署，业务相关的关联并无消除
友人 11:07:41

老碗鱼 11:07:49
嗯嗯
老碗鱼 11:08:04
你如何把控项目的关联关系呢
友人 11:09:01
就如这两个主体吧，拆成两个项目，本身负责本身的，而后调其余项目须要处理的接口，不须要只有其余项目的具体实现
友人 11:09:17
不须要知道
老碗鱼 11:10:42
那这里面存在一个远程调用事务的控制对吧
老碗鱼 11:11:34
而后开发什么接口对业务数据总体化处理须要作文档规范对吧
友人 11:13:16
是的
老碗鱼 11:13:58
个人思路如今是回收拆分
老碗鱼 11:14:07
不用拆分那么多项目
友人 11:15:05
怎么回收拆分
老碗鱼 11:15:25
拆分就是解决我刚才说的那个问题
老碗鱼 11:15:41
换种方式去解决那种问题
老碗鱼 11:16:05
让系统去规范数据的总体性
友人 11:18:38

老碗鱼 11:19:24
刚才说到表的增删改查
老碗鱼 11:20:31
对于公司业务来讲，业务其实也只有增删改查
老碗鱼 11:20:37
对吧
老碗鱼 11:21:38
赞同不
友人 11:21:50
赞同
友人 11:22:29
除了增删改查还能有啥操做
老碗鱼 11:22:58
对吧
老碗鱼 11:23:19
一个项目是分为多个模块
老碗鱼 11:23:47
这个模块就是以基本信息为主体和多个相关的附加信息
友人 11:24:05
嗯
老碗鱼 11:24:31
咱们以业务模块为基础提高一个维度
老碗鱼 11:24:50
面向业务模块的增删改查
友人 11:25:23

老碗鱼 11:25:37
理论上，这个维度能够无限制的提高
友人 11:25:43
增删改业务？
老碗鱼 11:25:48
对的
老碗鱼 11:26:04
并且是可控的

友人 11:26:29
就是把每一个模块在封装一层？
老碗鱼 11:26:47
能够面向业务模块，再提高能够面向项目，再提高能够面向全部
老碗鱼 11:27:31
无穷无尽的扩展下去，只要你的处理能力够大，他都会在这个框架下无限制扩大
友人 11:28:02
这么说有点难以理解，有没有demo
老碗鱼 11:28:15
没有，如今只是一个思惟模型
友人 11:28:39
抽象出来接口却是能够理解，你的这个。。。
友人 11:28:57
你本身想的？
老碗鱼 11:29:04
后面我能够将模块认为一个模块，也能够将项目认为一个模块，任何东西均可以是一个模块，无论什么开发语言
友人 11:29:29
有demo有真相
老碗鱼 11:29:34
对的，我本身想的
友人 11:30:18
这个就超脱出了mybatis的范围，应该是总体项目而已了
友人 11:30:52
如今很火的一个技术和你这个理念很像，微服务
老碗鱼 11:31:44
我知道微服务，但这些都面临这一个问题，当服务变得特别多的时候，业务关联性就会混乱
老碗鱼 11:32:18
我将这种业务关联性交给系统来管理