關於軟件設計的思考

友人 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
我將這種業務關聯性交給系統來管理