據說取個高大上的名字就會很多人看，所以就用了這個名字。

　　歷時兩個半月時間終于看完了《DDD》，嘆為觀止，雖然以前給很多新員工講過面向對象，不過看了之后才發現，原來理解還可以更深，還可以升華。它解決了很多困擾我的問題，甚至有的困擾了我幾年。下面準備用一到兩天時間再瀏覽一遍，然后把理解整理一下寫出來，如果寫的時候想的起來，就順便寫寫我之前的問題和一些事件過的思想什么的。另外，雖然我是逐字逐字讀下來的，但難免有些理解不清晰的地方，我理解了就會改回來的，嘿嘿。

　　據說人一生除了睡覺百分之四十多時間在走神（記不清了），我總覺得我能達到百分之七十以上，所以我又一次以走神內容為內容隨一筆，上次我是記得從哪開始走的，這次走的比較突兀，完全記不得是因為什么了。。。

　　一.面向過程

　　最早的應用程序，作用應該是幫助人們做一些重復性的工作，小學課本上人與動物最大的區別---工具。。。軟件。

　　比如說走路，走一步的時候是:

　　1.先抬腳跟（鞋跟，排除走路腳跟不沾地的人，比如某劇里的某星）；

　　2.腳尖向后蹬地；

　　3.腳離地，膝蓋微曲；

　　4.這個咱就不繼續說了，免得拖劇情，反正很多就是了。。。

　　這個時候的軟件幫助人類完成這些過程化的重復動作，因為要走好多步啊，每次都考慮一遍這么走好麻煩（懶人創造世界這話我就不說了），讓軟件去每次重復一遍這個過程，又省事，又不容易出錯，因為人難免走神嘛，漏個步驟就可能摔跤的，軟件就不容易漏，這個例子好麻煩就不寫代碼的例子了，總之面向過程就是這樣了，表述一個過程，幫助人們完成重復繁瑣的工作過程。

　　二.面向對象

?　　以上和以下都是拋開了硬件的影響，既然是走神，思維跳躍一些也是可以理解的...吧。上面說的走路這個過程，其實有很大限制的，比如說得是同樣的走法，同樣的環境，可能有時候還得是同一個人，因為有的人腿就是很長，有的人腿里還有鋼板膝蓋就是不能彎曲是吧。那我想走的更自在怎么辦，如果是從過程的角度來考慮，得判斷吧，判斷腳跟不沾地，判斷地，判斷水泥地，判斷泥地，判斷水地（？），判斷腿長短步子大小，判斷高跟鞋和重心的平穩之間的關系。。。還有好多什么什么的判斷，這程序要是改點需求還了得了，這就是要程序員命的節奏，要是現在要讓幾個人在不同的地上面走或者游，然后判斷幾個人哪個比較勤快，有進取心，走或游的比較賣力，算了，不敢往下想了

　　那怎么辦，先把判斷都抽出來看看，腳跟不沾地的是人不同，判斷地的是地不同...，不同的地走路依然是那么走，只是交互之間相互的作用力不一樣而已，一直以來想要變得簡單的辦法都是把變化的范圍縮小，讓變化方式和頻率不同的部分獨立，那在地的問題上，自然就是讓走路的方式和地分開，分別獨立，不同的人的走路方式不同，那就把不同的人也獨立開，這樣就體現除了對象的概念，現在有了腳跟沾地的人，腳跟不沾地的人，水，泥地，水泥地；這就變得和現實的情況一一對應了，現在瞬間就能發現好處，既然和現實是對應的，那我完全不要去考慮程序過程的邏輯了，有木有，我只要按照現實人與地的交互來描述對象（現在可以起名叫對象了）之間的交互不就完全實現了需求，而且不會有錯，因為就是照著現實的辦理描述了一遍的，這太輕松了，這部分我之前寫了個剪刀剪紙的隨筆描述了對象交互，例子就略了，總之，面向對象的思想出現了（那些建立了很多對象，但是依然在描述過程的人是得不到這個好處的，就不細說了）。

　　三.DDD

　　DDD獨立一個大序號，是因為它是我以后的重點，它依然是面向對象，但它是在一個大背景下的面向對象的升華。

　　接著走路，現在走路要走的精確點了，腳跟怎么用力，腳尖，小腿，膝蓋等等...，這些器官間的交互，再加上和地的交互，腳跟怎么對地，腳尖怎么對地，還有鞋的問題，在這種情況下，面臨了當初面向過程相似的問題，對象太多，對理解有很大壓力，不是說人最多只能記住七樣東西么，這么多對象難免思考怎么交互的時候會遺漏點什么，摔跤又難免了。就像小孩正常走挺好，但是走的太快，來不及協調所有對象，就容易摔跤；大人跑的可能很穩，但是那是因為協調了好多年才形成的，我們等的起，客戶可等不起...。怎么辦，同樣還是縮小范圍，將變化頻率一樣的東西放一起，走路時，人腿上的所有器官是協同變化的，形成了一個完整統一的系統，這個維持著一致性的系統起名叫聚合，現在又變回了原本面向對象的情況，協調又容易了。

　　現在再來看看上面那個比較哪個人更有前進心的問題，怎么比較呢，比較三種地，再聯系三個人，再比較三雙鞋，這時候其實還得考慮下，水里那位可不是只用了腳，而且水里的不趕緊游沒力氣了要喝水的外界因素，這種比較實在是有些頭疼。怎么辦，經典的方法之所以經典，就是因為好用啊，這里只要每個人所處的上下文歸為一個聚合，給三個聚合一個比例指數，那三個聚合只需要內部處理的結果于自己這個聚合的指數比較就出來了，而內部的處理因為是在同一個上下文中又有能保證一致性的關系，就輕松多了，這樣也把比較的范圍縮小了。從這個角度來看，DDD的對象是一個又若干有一致性關系的小對象形成的系統的對象，和傳統面向對象的外在表現其實并無不同，只是可能傳統的對象并沒有把人腿細化為各個器官的協作。

　　舉個正在開發的工作流的例子，審批的單據包含特定審批類型所獨有的單據內容以及相關的業務內容，業務內容中可能會包含一些明細，查看單據的場景就需要有三種對象：審批單信息，業務信息，業務明細信息，分別查看的話，每次都要關聯查詢三個對象的信息，這種查詢的邏輯每次不同的查詢方式都要做開發，比如發送審批郵件，移動端審批等，但其實這是沒必要的，因為這三種對象是有一致性關系的，這種穩定的一致性關系都由開發應用邏輯的程序員來重復維護是沒必要的（查詢，保存等都需要維護），那完全可以使用聚合，將一致性保持在聚合中，而應用邏輯只需要知道使用單據就可以了：

　　　　　　　　　　　　

　　業務信息和申請單信息會有很多種類，但這并不影響這個結構的穩定性，這個系統由于正在進行中，所以就不發代碼什么的了，而且由于是公司的系統，也不好說太細，開發完成以后我應該會做個總結，把能寫的地方寫出來的。

轉載于:https://www.cnblogs.com/saaav/p/3731901.html

總結

以上是生活随笔為你收集整理的应用系统开发思想的变迁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。