分類彙整: 設計原則

在世界是平的另一端，世界也愈來愈不平；因為整合愈來愈難，要有具備適應環境的變化無常的能力，才是委外服務提供者的功力。事實上，開發企業軟體，並不如一般人所想的「業務流程決定軟體程式，軟體程式追隨業務流程」那麼簡單呀。 閱讀全文 →

以企業層次的策略觀點來看，核心能耐在於整合各事業體（business unit）以產生綜效。所以，有關核心能耐的問題並不在於如何分工，而是在於有效整合。企業價值鍊活動必須有效地整合才可以破除分工的迷思，要做到這一點，資訊技術往往扮演關鍵的角色。 閱讀全文 →

在〈石頭閒語：類別繼承、介面宣告與模組混成(mix-in)〉，石頭成提到他的學習 … 閱讀全文 →

看了喲哪桑學長寫的〈Rule of Thumb in Program Log〉， … 閱讀全文 →

最近有人找我討論專案中日誌功能的整合問題，他認為以 log4j 實作的 Logg … 閱讀全文 →

在〈物件 (Object) 的媽媽是 類別 (Class)？〉一文中，Kenmi … 閱讀全文 →

在〈軟體設計需面對現實〉一文中，我曾針對 Gameboy 提出「用 real w … 閱讀全文 →

最近看到有人領域模型中的客戶類別如此設計： 這個設計觀點是將個人戶與公司戶都看成 … 閱讀全文 →

最近HSDc有一篇文章，主題是《繼承或是一般化？》，作者Ringle Lai認為 … 閱讀全文 →

其實國內的workflow engine廠商其實都聲稱符合WfMC工作流程標準，但一般人很難了解它們各模組間是否有做到真正的分離。曾問過幾家workflow engine要如何整合其應用程式，所得到的答案多半是「客製化」這個專業術語，但進一步了解才發現，他們並未設計界面來做為減震點(Decouple Point)以減少不必要的模組相依，而是模組必須和特定的實作緊密耦合在一起，也就是他們的客製化會使原先定義良好的模組被破壞了。因此可以推知他們並不是採用模組分離的設計，也就是並未符合所謂的模組鬆散耦合的理想。我想這當中除了作業環境會有不相容的問題外(Web base vs. AP base)，更重要的原因就是市場利基的考量，技術問題容易克服的，但workflow市場恐怕還沒具備須鬆散耦合設計的條件。 閱讀全文 →