软件构造的步骤
?
軟件構造從用戶需求開始
需求即用戶對軟件功能的描述，用戶通過需求告訴程序員他需要收集什么數據，這些數據該怎么處理，最后他希望看到什么結果。需求中描述的場景和內容是軟件處理的核心領域，程序員需要通過代碼把它表現出來。?
即使用戶是和你一樣的程序員，需求也不可能完善到直接指導編碼的地步，而且軟件的構建是一個“邪惡（Wicked）”的過程，也就是說某些問題在設計階段并不顯山露水，只有在構建過程中它們才會逐漸暴露出來。這就要求程序員深入問題的領域，了解領域的相關知識，對領域做出合理的抽象，并在軟件構建過程中不斷完善它，直到完全實現用戶需求，具備現代軟件的八個主要特征。
?
二。何謂領域和領域模型
?
領域即業務領域，是用戶進行業務活動的主要內容。一些領域是和現實世界中的實體對應的：如雇員管理系統中的雇員，圖書管理系統中的圖書，零售系統中的商品，而有些領域
和現實世界中的虛擬實體相對應：如金融系統中的借貸關系，商務系統中的合同關系等。軟件的主要任務是數據的收集，整理，表現，存儲和傳輸，而數據的基本單位就是領域模型。
?領域模型是現實世界中的實體在代碼中的體現和合理抽象，它能表現出實體的基本信息。如果可以說軟件環境是現實業務活動在計算機世界的模擬的話，那領域模型就是現實實體在計算機世界的模擬。
?
三。軟件構建的核心是領域模型的建立
?領域模型是軟件需要處理的數據的基本單元，只有建立起了領域模型，你才能知道軟件需要收集，整理，表現，存儲和傳輸的對象是什么。建立領域模型是軟件構建的核心環節，如果它沒有被合理抽象出來的話，
軟件能提供的服務，數據的持久化和數據在軟件中的表現都是空中樓閣，因此我們可以說，從現實世界中的實體中抽象出合理的領域模型是軟件構建中提綱挈領的一個環節，這一步是軟件各個層次
的基石，也是軟件構建的起點。不建立領域模型并非一定不能造就出能運轉正常的軟件，所謂的表維護程序就是典型例子，它們由某些懶惰，愚蠢和無能的程序員造就，他們從來不去認真思考用戶究竟想知道什
么，程序究竟在處理什么，而是翻譯堆砌代碼，僅僅讓它能跑出一個正確的結果而已，這樣的程序員永遠成為不了優秀的程序員，他們生產出的代碼也是一堆有危害性的幾乎無法維護的垃圾，這堆垃圾將給公司和個人帶來潛在的危害，相對而言，對個人的危害性更大，有時甚至可以斷送一個程序員的職業生涯。
?
四。如何建立起領域模型
?
途徑一：分析業務中的業務流和業務規則，從中歸納出功能的基本單位，這個基本單位就是領域模型之一或領域模型的一部分。
?
途徑二：從原型界面中觀察顯示的數據，它們是領域模型的外在體現。
?
途徑三：從持久化介質中推導領域模型，如從數據庫的表結構和ER圖中推導領域模型。
?
途徑四：向領域專家問詢業務流程中的核心單元是什么，甚至自己進入問題領域去學習探究。
?
途徑五：將不熟悉的領域和相似的自己熟悉的領域做對照，類比出領域模型。
?
途徑六：從已有的知識系統中學習，參考功能相似的軟件代碼，向優秀代碼學習。
?
五。如何完善領域模型
領域模型是經常發生相互聯系的，上一步只是建立了孤立的，僅能表現單個領域對象信息的模型，要使它們豐富完善起來，需要做以下工作：
?1)
從程序的功能角度入手，考慮需要幾個領域對象才能完成這個功能，再由此考慮領域對象之間的聯系。這方面的典型例子是需要雇員類和資源類的協助，借貸關系才能完整的表現出來。
2)
從領域對象本身入手，考慮領域對象之間是否有級聯，回溯，包含等常見關系。如個人信息包含地址信息，公司類和雇員類的級聯關系，雇員類查找自己所屬公司的回溯關系等。?
3)
從反持久化入手，考慮把一個領域對象從存儲介質中提取出來需要那些領域對象的幫助，這些領域對象是通過那種方式聯系在一起的，這方面的典型例子是表之間的主鍵和外鍵，領域對象同樣也要具有相對應的成員變量。
?
六。領域對象設計完成之后
一旦領域對象設計完成，程序的設計工作就可以說完成了一大半，其余工作都是圍繞領域對象來進行，這些工作有：
1)
從考慮怎么為領域對象服務入手，為領域對象設計服務類，服務類的常用方法有添加，刪除，更新，查詢領域對象四種以及從ID取得一個領域對象，判斷持有某個ID
的領域對象是否存在等。具體的操作實際上由服務類的持久層類成員完成，服務類實際上起到的是一個領域對象上下傳輸通道的作用。一般來說Service
層的六大函數是add，delete
?
轉載于:https://www.cnblogs.com/xxdcxy/p/6417184.html
總結
- 上一篇： updater.exe是什么
- 下一篇： maven+jenkins自动化构件