反觀如今的博客也好，技術文章也好，多是某一方面的技術細節,我個人不太喜歡這個方向,覺得意義不大。這些確實都是知識,我也十分尊重和感謝這些作者的貢獻，因為我碰到問題也經常搜索這樣的技術文章而得到了幫助。
可是，這與軟件公司的實際工作總有個巨大的鴻溝，經常也看到很多人也類似的困惑，看了眾多技術文章后，依然迷茫?更有人把這些困惑訴諸於文字。
商業軟件注重的是技能,是所有技能的大整合，而不是技術點的羅列。把一個C#語言特性講得再多再深,也只是MSDN幫助的一個翻版,也永遠成不了商業軟件。相反,講解技術的代碼示例,幾乎都是商業軟件的反面教材。
偉大的作家都是閱讀了大量作品，從中汲取營養，才逐步成長，最后成為大家。可是，諷刺的是， 同是作為思維作品的軟件設計，卻較少有這種機會，各個公司都是互相封閉，甚至極其仇視代碼分享的想法，美其名，版權。而開源的興起，可以說，這個是最大的益處。只是，大多數開源者，本身都沒有意識到。所以，發布是，仍然過於注重，軟件的功能，而不是設計。
這里，不得不提一下源代碼管理軟件Git，與SVN和TFS相比，Git最大的特點就是就是業務域模型設計非常精彩，后兩個都是基於文件的版本控制，而Git是基於整個代碼樹的版本控制。什么是DDD看看Git的業務模型，會有不同感想。誠然，Git的終端功能和用戶使用上還有所欠缺，那只是時間的問題。相比之下，TFS和SVN雖然提供的最終功能很好，但由於底層設計的缺陷，這些功能如補丁一樣，沒能和業務模型融合到一起，終究會支離破碎。我很看好Git的將來。
目前,我正在組建團隊,開發實際項目。並逐漸提煉完成了自己的一套框架。在這個過程中,融合消化整合了大量的技能。
現在,我想做的是個反向工程,解構這套框架,把設計思想,整合過程又一步步拆散,呈現給受眾。這也是我之后技術作文的方向。這樣的方式內容，不知諸位有何看法？
這里是技能的整合幾個例子:
- 三層架構的需要解構依賴關系（表現層依賴於業務層，業務層依賴於數據層），才能發揮更好的作用。如：用Repository隔離業務層和數據層，Repository的接口定義屬於業務層層，而實現卻屬於數據層；用DTO（ASP.Net MVC稱為View Model）來隔離表現層和業務層。然而，增加的復雜度又如何解決呢？
- 為了實現測試驅動(TDD),需要利用依賴注入(DI)來隔離類與類之間的直接聯系,還要用AutoMock來提高寫測試代碼的效率,最后,進一步用用戶故事的語法來組織測試代碼,提高代碼的可讀性。遺留的問題是具體代碼如何,有哪些已有工具可利用（nUnit, Machine Specification, Ninject, Resharper等等） ?
- 業務域驅動(DDD)與ORM工具Fluent nHibernate的一起使用,大大提高效率,注意是Fluent,幾乎可縱做到零SQL, 零數據庫表定義。
可以看到,各種概念的交互,融合,最終有機的成為一個整體。
（本文版權屬於© 2012 - 2013 予沁安 | 轉載請注明作者和出處WangHaoBlog.com）