这种架构的优点在于极度的分布式。从外观上看起来一致的系统，实际由若干个耦合极低、技术架构完全不同的小应用组成。它们不需要被部署在同一台机器上，可以单独地开发、升级、优化。一个应用的瘫痪不影响整个系统的运行，大连钉钉办公系统二次开发以后自行升级对整个系统也完全没有影响。

      致远服软认为：http://www.soft8.com.cn/这并非是终极的解决方案，只在某些特定的条件下有效。当系统规模上非常庞大，例如由若干个子系统组成，界面基本一致，子系统之间关联较少，针对这个前提，我们可以考虑采用这种架构抽象出极少的、真正有效公用的信息，在系统之间通过HTTP POST。其他的系统完全可以独立开发、部署，甚至针对应用访问的情况进行特定的部署优化。如果不这么做，动辄上百万千万行的代码堆在一个系统中，随着时间的推移，开发者逐渐对代码失控，架构的腐化是迟早的事情。

      例如，银行的财务系统包括了十多个个子系统，包括薪资、资产、报表等模块，每一部分功能都相对独立并且复杂。整个系统如果按照这种方式拆分，就能够实现单点优化而无需重新启动整个应用。针对大连钉钉办公系统二次开发应用，开发者能够在更小的代码内采用自己熟悉的技术方案，从而减少架构腐化的可能。

      我访问过很多大连钉钉办公系统二次开发团队。在很多项目开始的时候，他们花很多时间在选择用何种技术体系、何种架构乃至何种 IDE。就像小孩子选择自己钟爱的玩具，我相信无论过程如何，团队最终都会欣然选择他们所想要的并且坚信他们的选择没有错误。事实也确实如此。在项目的开始阶段很难有真正的架构挑战。困难在于，随着时间的增长，人们会忘记，有很多的人加入，他们需要理解旧代码的同时完成新功能。每一次代码量的突破都会引起架构的不适应，这些不适应包括：新功能引入变得困难、新人难以迅速上手、构建时间变长等。我们不知道这些能否引起团队的警觉并且采取结构性的解决方案，而不是临时性的。

      很多人说敏捷不提倡文档。他们说文档很难写，大连无人值守停车场计费软件开发人员写不了文档，于是就没有文档。

      奇怪的是我看到的情况却不是这样。程序写得优秀的人，写起文字来也很不错。ThoughtBlogs上绝大多数都是程序员，很多人的文字写得都很棒。