有很多網站教會人們如何構建更好的軟件，但爲什麼只有很少的網站能真正詳細描述我們（作爲程序員）應該創建的領域？人們只能在不同類型的系統中出現通用需求模式之前，才能構建如此多的庫存，會計和ERP系統。從邏輯上講，如果程序員花費很多時間在架構中創建可重用組件，這是否意味着他們應該有一些可重用的「藍圖」來描述他們應該創建的系統？換句話說，軟件開發的重點似乎過於集中於「如何」構建軟件，而不是編制目錄並準確指定（具體要求）「首先應該使用什麼」。爲什麼這麼多網站討論編程而不是描述他們試圖製作的系統呢？
所以我的問題是這樣的：是否有任何工作將所有不同類型的系統規範編入一個地方，所有這些都在一個站點上？如果在項目開始階段缺乏適當的要求是軟件開發的障礙之一，那麼從以前已經寫入的相同類型的系統中'重複使用'需求規格是否更有意義？
有一個網站Database Answers試圖爲常用的數據庫設計提供解決方案，這不同於你描述的完整解決方案，但它是一個步驟正確的方向灰。
您評論「[o] ne只能在共同性變得明顯之前構建這麼多系統。然而，那些構建了足夠的這樣的系統來發現共同性的人，然後試圖通過創建它們的通用系統版本來從中受益，然後將其出售。這不是（被認爲是）爲了他們的利益而讓其他可能做同樣事情的人得到幫助。
我完全同意，「Dummy的IT存貨指南」，客戶的認可數據模型，地址和聯繫方式等等。我發現自己在許多不同的地方重新實施相同的代碼，與微妙的不同領域和邏輯，但基本上是相同的東西。幾年前，我發現了一個預煮數據模型的網站 - 向正確的方向邁出了一小步，但不是整個故事Universal Data Models（無連接）。你會注意到他們對他們的產品沒有太大的興趣。
我也曾在一些組織中開發自己的「通用」數據模型作爲可銷售產品。其中一位在金融服務領域，他們獲得了1500多個DB2表，並放棄了。組織以自己的獨特性而感到自豪，而我們（技術人員）意識到，在大多數情況下，他們都做了非常類似的事情 - 我認爲這可能對企業自我造成太大的損害，並承認他們與其他人一樣使用UniversalCustomer（TM）1.7。此外，這使得這些公司已經成熟了一些SAP，Peopleware等。
作爲最後的想法 - 這裏的企業家有很多低掛的成果。一本體面的描述公共領域的簡短書籍。我的意思是超級簡單的東西，人名，地址，電話等 - 所有的小小弱點像不同文化中的標題，處理電話號碼 - 現在有很多人可以使用的書/維基。
公司正在做類似的事情，但業務流程都是獨一無二的，很少有可以應用的通用解決方案或數據模型/規則集 - 總是有例外，這會破壞應用通用性的嘗試。 – simon 2009-11-06 23:08:05
誰會創造這樣的事情？誰會使用呢？
附近我可以告訴你，你正在談論一個應用程序設計庫。處理分享這些詳細設計的人已經這樣做了 - 以開放式規範或開放源代碼的形式。前者傾向於吸引大多數已經參與創建實現這些規格的產品的人員和組織，或與可以實現這些規範的系統互操作的產品。後者......好吧，爲什麼要重新實施設計，當你可以破解源代碼？
由於Mark Harrison notes，有是許多公司願意推廣他們的設計的通用業務系統。 「購買我們的系統，只需爲您的組織提供必要的功能」，他們會告訴你; 「爲什麼浪費時間重新實施我們已經完成的事情？「他們分享詳細的實施規格的動機非常小，因爲他們真的不希望你重新實施他們想賣給你的東西。
終於......這些事情真的不是那麼簡單或者更確切地說，他們是......但是複雜性的規模已經超出了規模，這是因爲任何組織都可能對系統施加不同的神祕要求組合，真正的工作是解釋這些要求，雖然它可能是單調乏味的，但它是不可避免的。
這將是無法兌現的。任何人爲系統發佈詢價都無法得到的第一個結論是：「我們不像其他公司，我們的要求是獨一無二的。」 （而且從來不是真的。）
如果您打算重複使用這些需求，那麼您也可以重新使用該代碼。但在較低的層面上，我認爲你所尋找的將是「需求模式」，與「編程模式」一致。
現在here is a book來自微軟的主題，但與所有域模式一樣，它的想法是它們應該有機地增長並適合域用戶和專家的需求。如果你想要真正的想法來源，請查看seminal book on patterns，儘管它來自架構而不是編程，但意外的驚喜:)
政府有各種努力嘗試和標準化數據模型以實現不同機構之間的共享，但這些在需要的地方以外幾乎沒有採用。例如在加拿大，我們有CPSIN。
查閱數據模型資源手冊由倫·錫爾弗斯頓：
它接近可重用設計從視數據模型點，相對於最終用戶的要求或OO設計。但是，我發現這非常有用 - 一旦你對數據模型有了很好的理解，就可以在需求和最終將被建模爲類的實體上大幅跳躍。
在我的經驗中，它分崩離析是用戶界面包含的用例。實際上，我設計並建立了廣泛應用於各種組織和行業（電信，食品，醫療保健，電子製造和分銷，消費品，服裝，航空航天等等）的庫存系統。在上半年，一個好的數據模型出現了，它們的變化很小（擴展，但不是變化）。
即使在一個行業內，由於任何原因（產品的性質，數量變化，平均訂單大小的進出，會計要求，員工激勵等等），工作是通過真實人們差異很大，原因很多。
請注意，上面的例子似乎都是關於更深入的抽象層次 - 特別是數據模型 - 我們程序員可以按照我們的方式來做到這一點，這對我們有利。離我們移動的用戶越近，我們的興趣就越需要成爲他們的次要目標。
最糟糕的例子：是否有其他人注意到員工排班和工時報告系統中的模式，每個屏幕顯示一週，以及多屏幕數據輸入表單？
在80年代和90年代早期，有一個巨大的「軟件重用」運動。人們在建立和調整軟件組件目錄時有相當大的行業。許多人認爲它是軟件的未來。 Will Tracz的「用過的軟件推銷員的自白」很好的概述;谷歌條款「布拉德考克斯軟件集成電路」，「馬丁格里斯」。我記得，勝利已經宣佈，所有人都轉向其他問題。
我看到布拉德·考克斯的「規劃軟件工業革命」是在線：
http://www.virtualschool.edu/cox/pub/PSIR/
你可能想看看Martin Fowler的Patterns of Enterprise Application Architecture - 雖然不規範，這似乎是對那種東西你在之後。
聲明：我自己沒有讀過，我只知道它的存在。
擁有代碼模式和各種語言的中央存儲庫會很好。然後，我們都可以炫耀我們令人驚歎的代碼，更容易互相學習，並通過提供xyz服務/產品的良好範例來提高整體代碼質量。
我的意思是，我們有多少獨特的編碼項目，沒有其他人做過？
我粗略的猜測是，我們工作的98％是其他人在許多不同公司，類似行業以及類似功能需求中所做的工作。
我的意思是這是那種stackoverflow應該得到的東西。不僅要分享和討論問題，還要學習彼此的代碼。
爲什麼3投票結束？這是一個很好的問題 – 2009-01-19 04:58:41
駕駛者。沒意見。不幸的是，這是詛咒。這太糟糕了，沒有辦法投票來減少計數。 – dkretz 2009-01-19 09:12:15