這種架構(gòu)的優(yōu)點(diǎn)在于極度的分布式。從外觀上看起來一致的系統(tǒng)，實(shí)際由若干個(gè)耦合極低、技術(shù)架構(gòu)完全不同的小應(yīng)用組成。它們不需要被部署在同一臺機(jī)器上，可以單獨(dú)地開發(fā)、升級、優(yōu)化。一個(gè)應(yīng)用的癱瘓不影響整個(gè)系統(tǒng)的運(yùn)行，大連釘釘辦公系統(tǒng)二次開發(fā)以后自行升級對整個(gè)系統(tǒng)也完全沒有影響。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/這并非是終極的解決方案，只在某些特定的條件下有效。當(dāng)系統(tǒng)規(guī)模上非常龐大，例如由若干個(gè)子系統(tǒng)組成，界面基本一致，子系統(tǒng)之間關(guān)聯(lián)較少，針對這個(gè)前提，我們可以考慮采用這種架構(gòu)抽象出極少的、真正有效公用的信息，在系統(tǒng)之間通過HTTP POST。其他的系統(tǒng)完全可以獨(dú)立開發(fā)、部署，甚至針對應(yīng)用訪問的情況進(jìn)行特定的部署優(yōu)化。如果不這么做，動(dòng)輒上百萬千萬行的代碼堆在一個(gè)系統(tǒng)中，隨著時(shí)間的推移，開發(fā)者逐漸對代碼失控，架構(gòu)的腐化是遲早的事情。
例如，銀行的財(cái)務(wù)系統(tǒng)包括了十多個(gè)個(gè)子系統(tǒng)，包括薪資、資產(chǎn)、報(bào)表等模塊，每一部分功能都相對獨(dú)立并且復(fù)雜。整個(gè)系統(tǒng)如果按照這種方式拆分，就能夠?qū)崿F(xiàn)單點(diǎn)優(yōu)化而無需重新啟動(dòng)整個(gè)應(yīng)用。針對大連釘釘辦公系統(tǒng)二次開發(fā)應(yīng)用，開發(fā)者能夠在更小的代碼內(nèi)采用自己熟悉的技術(shù)方案，從而減少架構(gòu)腐化的可能。
我訪問過很多大連釘釘辦公系統(tǒng)二次開發(fā)團(tuán)隊(duì)。在很多項(xiàng)目開始的時(shí)候，他們花很多時(shí)間在選擇用何種技術(shù)體系、何種架構(gòu)乃至何種 IDE。就像小孩子選擇自己鐘愛的玩具，我相信無論過程如何，團(tuán)隊(duì)最終都會(huì)欣然選擇他們所想要的并且堅(jiān)信他們的選擇沒有錯(cuò)誤。事實(shí)也確實(shí)如此。在項(xiàng)目的開始階段很難有真正的架構(gòu)挑戰(zhàn)。困難在于，隨著時(shí)間的增長，人們會(huì)忘記，有很多的人加入，他們需要理解舊代碼的同時(shí)完成新功能。每一次代碼量的突破都會(huì)引起架構(gòu)的不適應(yīng)，這些不適應(yīng)包括：新功能引入變得困難、新人難以迅速上手、構(gòu)建時(shí)間變長等。我們不知道這些能否引起團(tuán)隊(duì)的警覺并且采取結(jié)構(gòu)性的解決方案，而不是臨時(shí)性的。
很多人說敏捷不提倡文檔。他們說文檔很難寫，大連無人值守停車場計(jì)費(fèi)軟件開發(fā)人員寫不了文檔，于是就沒有文檔。
奇怪的是我看到的情況卻不是這樣。程序?qū)懙脙?yōu)秀的人，寫起文字來也很不錯(cuò)。ThoughtBlogs上絕大多數(shù)都是程序員，很多人的文字寫得都很棒。
