关于软件设计的思考

友人 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
我将这种业务关联性交给系统来管理