同人前幾天和某位 SA 討論某項作業的功能，討論到一半有長官跑進來加入意見。他希望我們按照他建議的方式來設計，卻否認我提出問題的設計概念的語意模型。他表示他比我們都要清楚業務模型，他認為我們需要解決技術問題應該用技術來解決而非業務，而同人表示反對的意見純然是技術眼光不懂業務，所以我根本是錯的。
長官的批評和指教讓我覺得「秀才遇到兵，有理說不清」。同人不願意對他批評我的斷言去爭辯，在雙方高度意見分歧的情況下，我決定中止討論。我表示彼此沒共識那就不用再爭辯，反正這個作業功能的設計需要改變，並不是很急迫的事，還是等到大家有共識再說吧。然後我離開了會議室，留下不高興的長官和無辜的 SA 在會議室中繼續討論。
當同人決定離開會議室之時，面對長官的指責我也不高興，當然在言語上，我並沒有指責他的錯誤，只是指出雙方沒共識的事實，建議等大家想清楚後再來討論。我當時不高興是因為不認同他提到「抽象化是技術觀點」的看法，事實恰好相反，抽象化是認清問題本質的思考過程，它必須隱藏及略除技術細節，目的是為我們找到問題的關鍵點。同人認為長官對抽象化的錯誤想法真是大錯特錯。
我們爭論的問題源自於該項作業需要記錄作業當事人的改變歷程。原先同人設計的架構可以在同一個交易之中，記錄每一個作業當事人在作業之前的原始狀態、以及作業對當事人的異動。為了讓設計更簡單，當事人的同一種異動只允許發生一次；也就是同一個當事人在作業中發生修改、或刪除動作只能一次。但 SA 負責的作業功能，卻有需要同一個當事人修改多次的情況。
了解作業當事人需要記錄在作業之中的改變歷程，同人建議該作業可以使用兩個作業識別碼，這樣每一個作業識別碼就可以對應相同當事人記錄的改變歷程。一個作業使用兩個作業識別碼，業務邏輯的處理似乎也不複雜，因為我們可以改變作業識別碼的定義代表識別作業的流程步驟，似乎可以滿足該作業的處理需求。但後來長官知道我們的設計之後，卻以不容易維護為由希望同人修改設計，要能夠把當事人在作業的改變歷程對應到相同的作業識別碼。
在和 SA 討論之前，同人已經先行和 PG 討論過各種可能做法的可行性，同人發現要滿足需求最直接而簡單的做法，就是把當事人改變歷程記錄到不同的資料表，而非記錄當事人的多筆修改資料。同人向 SA 提出我的設計想法：如果不要在一個作業當中使用兩個作業識別碼，那應該就需要定義另一個資料表，用來記錄不同修改用途的資料。
如此我們就可以用不同實體記錄資料的改變歷程，也就不會有同一筆當事人資料有連續兩個修改紀錄的問題，但長官中途插入我們的討論，卻反對同人的做法。他說這樣每一個在作業當中需要對同一個當事人處理多個階段的情況，都需要為每個階段定義一個資料表。強調客戶的需求常常改變，所以「可能」以後會常發生一個作業同一個當事人會有多次變更的資料狀態，他表示同人的做法等於是 Hard Code，認為技術的問題就要用技術解決，而不是在作業當中做不一樣的處理。
這位長官的意見是希望我們在作業識別碼採用 Master-Detail 的設計，但同人和 PG 討論過這種設計，這樣只會更複雜而衍生各種無法預期的問題。而且更讓同人不願採用這種做法的原因是它不是站在問題的本質上思考問題，只是以嘗試以技術解決各種「可能發生的所有問題」，無疑是犯了「沒問題症候群」的毛病。長官的想法顯然是不合邏輯的，這不是技術上的問題，而是因應業務問題衍生的特殊需求，必須從領域概念的角度來思考問題。
同人知道長官不想聽設計有「不完備定理」的問題，就算他聽了恐怕也無法體會設計的一致性和完備性往往是相互矛盾的。我只是很簡單地在白板上畫出交易－作業－處理階段的關係，並說明如果作業不想分開，在概念上就必須用不同資料表區分不同的處理階段。但長官卻只是用他認定的主觀意識宣稱他比較懂業務需求，質疑同人用技術的眼光看事情是錯誤的。
同人反駁領域概念的抽象化思考並不是技術眼光，我所表達的是領域概念的語意模型。然而，他的反應還是不斷地宣稱他是對的，我是錯的，沒有辦法表達客觀理性的觀點，卻一再地用個人主觀偏見說他不想談理論（拜託！如果真正實作出系統的人講的是理論，那他講的又是什麼？）。同人不想再跟他辯論誰的價值觀比較優劣的問題，於是我表示「沒共識再討論下去無謂的爭辯也沒有意義，等以後有共識再來談吧！」，然後獨自離開會議室。
從上圖可以看到比較清楚的領域概念模型，雖然它是用 UML 的類別圖畫出來的，但它表現的是概念性的抽象語意，而不是表現具體的技術細節。把這張圖表達的概念當成技術觀點，那是不明白抽象化思考的巧妙與關鍵之處。抽象化的目的並不希望看到巨細彌遺的技術細節，而是希望隱藏繁瑣的特殊化技術細節，以顯示比較重要的一般化抽象概念（Key Abstraction），期待從問題本質的理解來更有效率地解決問題。
對於以上有關於抽象思考的觀點，同人常會聽到批評者說：「哎呀，這些觀念我都知道，但是它們只是理論！」每次聽到這種說法，我的解讀是說這種話的人以為他知道，但其實他並不知道他不知道。因為他根本缺乏經驗去真正地認識他所知的侷限和狹隘。雖然同人的經驗可能可以幫助他知道他並不知道，然而當對方執著於自己的經驗，卻不肯靜心傾聽別人的意見來共享語意庫，那麼無謂的爭論只會增加彼此的對立和衝突，並且讓負面情緒破壞雙方關係，這絕對不會是處理問題的明智之舉。
當然，要瞭解用 UML 的類別圖所畫出來的領域概念模型，對於不懂 OOAD 的長官而言，這真的是難了一點，但如果討論問題可以因為看事情角度不一樣就否認由別人所表達的觀點，就算他一再地宣稱他是對的，別人是錯的，他仍舊還是錯得離譜。抽象化思維沒辦法只從單一角度來思考問題，否則如何從各種差異點來歸納出有用的共通性呢？依我看，排斥不可以有不同觀點的差異性，只是因為害怕思考活性不足或是無法採取行動來掌控變化的掩飾行為而已。
管理人員常常用兩種說法來否認技術人員提供對問題的回饋，第一種說法是「它和技術無關」（It’s not about the technology, INATT）、另一種說法則是「我是客戶的代言人，客戶永遠是對的，所以我一定是對的」。但這些說法的最主要的迷思是解決問題的複雜性需要具備「多樣性」的團隊，而非刻意降低團隊的多樣性。因此只從業務需求的角度不見得可以看到解決問題的關鍵本質，反而從技術的另類思考可以讓人發現從業務觀點看不到的更為有用的新概念。
同人這樣說不是代表技術才是解決問題的關鍵，而是解決問題需要因地制宜。我們每次碰到需要解決的狀況都不盡相同，因此都會需要各種觀點的參與，讓彼此產生互動，進行對話而共享意義。所謂的抽象化思維就是從不同觀點的互動中，經由演化而創造出全新的不同觀點；它既不是業務觀點也不是技術觀點，而是彼此交織之後產生有用的解決問題觀點。其實把抽象化當技術的繆誤，不單單只出現執著於業務觀點的情形，執著於技術觀點也會犯了相同的錯誤；以為堅守特定觀點就可以解決問題，然而這樣的繆誤讓我們缺乏解決問題所需要的彈性呀。
