<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>I&#039;m CaLendarW Blog &#187; architecture</title>
	<atom:link href="http://wongkalun.idv.hk/category/software-engineering/architecture/feed/" rel="self" type="application/rss+xml" />
	<link>http://wongkalun.idv.hk</link>
	<description>任何時間，都要用內心既一點光，照亮世界</description>
	<lastBuildDate>Wed, 07 Dec 2011 15:39:51 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Great software is not built, it is grown</title>
		<link>http://wongkalun.idv.hk/2009/06/18/great-software-is-not-built-it-is-grown/</link>
		<comments>http://wongkalun.idv.hk/2009/06/18/great-software-is-not-built-it-is-grown/#comments</comments>
		<pubDate>Wed, 17 Jun 2009 16:01:43 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[翻譯]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=547</guid>
		<description><![CDATA[作為一個架構師，主要任務是提供了初部結構和安排不段增長和隨著時間而改變的軟件系統，而且幾乎總是在你和利益相關者沒有預見下重做，或者和其他系統溝通。儘管我們是所謂的架構師，我們由建築和工程方面借用了許多隱喻，但偉大的軟件不是建造，而係成長出來的。 唯一最大既避免軟件失敗係軟件規模;由大型系統開始設計幾乎沒有任何好處。然而，在某個時候我們都將受到誘惑而這樣做。除了作為容易附帶的複雜性和慣性，設計大型系統的前期意味著更大的項目，這些項目更有可能失敗，更可能是無法測試，更可能是脆弱的，更可能有不必要的和不使用的部分，更可能是昂貴的，而且更有可能產生不利因素。 因此要抗拒試圖設計一個大型完整的系統，無論是多麼誘人，以“達到或超過”已知的要求和期望的特性。已經是一個宏大的目標，但不一定是一個大的設計。令你同你的系統學習適應環境及不可避免的改變。 如何做到這一點？最佳的途徑係從一開始確保軟件系統可以成長和適應不斷發展。誘導系統成長代表從一個較小的系統運行，做一部分架構既工作 &#8211; 做最簡單而最有可能完成的部份。這初生的的系統將有很多可取的性能和能教育我們了解更多大型系統的架構，或者更糟的一堆架構文件。你更有可能參與了其實現方法。而細小的介面將可更輕鬆地進行測試，因此不容易耦合。這只需要一個較小的團隊，間接降低協調項目的成本。而且其特性將會更容易被觀察，更輕鬆地部署。它會教你和你的團隊在最早的時刻知道什麼做到和什麼做不到。它會告訴你的系統不會容易發展、有可能是堅固、或者係脆弱、又或者有可能被破解。也許最重要的是可以從一開始給予利益相關者一些理解和確實的情況，使他們能夠為整體設計成長。 設計最小的系統，您可以幫助實現它，並讓它朝著宏偉構想。雖然這可能會覺得自己放棄了控制，甚至推卸的責任，最終您的利益相關者將會向你表示感謝。不要混淆循序漸進的辦法與不理要求，可怕的逐步，或建設一個將會扔掉的系統。 ############################################## As an architect you are tasked with providing the initial structure and arrangement of software systems that will grow and change over time, will have be to reworked, will have to talk to other systems, and almost always in ways you and your stakeholders did not foresee. [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/06/18/great-software-is-not-built-it-is-grown/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Separation Of Concerns</title>
		<link>http://wongkalun.idv.hk/2009/04/26/separation-of-concerns/</link>
		<comments>http://wongkalun.idv.hk/2009/04/26/separation-of-concerns/#comments</comments>
		<pubDate>Sun, 26 Apr 2009 08:20:24 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[SoC]]></category>
		<category><![CDATA[精華]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=477</guid>
		<description><![CDATA[係軟件設計方面, 其實主要都想將唔同既 Concern 分開, 以我做開主要有以下幾個: Flow / Business Logic Input (Import Data, Interface for 3rd Party) Output (User Interface, Report) Database Logging Permission 在以上幾個 Concern 上, 而 Logging 同 Permission 呢兩樣野其實應該可以重用, 而且應該可以視為另一個軟件 / Domain Area. Database 使用方面, 因為市面有不同種類既選擇, 而為左可以應用係唔同 Database 上, 好多人都會加上一個 Data Access Layer, 正常既 implement 手法都係 Object Relational Mapping, 在 .net 主要有 LGPL [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/04/26/separation-of-concerns/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>97 Things Every Software Architect Should Know</title>
		<link>http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/</link>
		<comments>http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/#comments</comments>
		<pubDate>Sun, 29 Mar 2009 05:08:39 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=409</guid>
		<description><![CDATA[近期睇緊 97 Things Every Software Architect Should Know 既 post, 入面有好多被公認 Software Architect 要知既事情, 我想如果要做到專業既話, 入面每一樣野都應該深入了解下!!! 除此之外, 仲有 Other Things Software Architect Should Know, 部份只有標題, 不過都理解到那些標題要深入研究的話係有難道的. dtsv.dtse_post_409_permalink = 'http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/'; dtsv.dtse_post_409_title = '97 Things Every Software Architect Should Know';]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2009/03/29/97-things-every-software-architect-should-know/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Object Relational Mapping 用後感</title>
		<link>http://wongkalun.idv.hk/2008/03/17/obect-relational-mapping-%e7%94%a8%e5%be%8c%e6%84%9f/</link>
		<comments>http://wongkalun.idv.hk/2008/03/17/obect-relational-mapping-%e7%94%a8%e5%be%8c%e6%84%9f/#comments</comments>
		<pubDate>Sun, 16 Mar 2008 16:03:41 +0000</pubDate>
		<dc:creator>calendarw</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[nhibernate]]></category>
		<category><![CDATA[orm]]></category>

		<guid isPermaLink="false">http://wongkalun.idv.hk/?p=28</guid>
		<description><![CDATA[自從轉左用 ORM 既 NHibernate, 以及公司某 Project 用左 Hibernate 之後, Overall 感覺都係慢既問題, Load 500 個 record 可能要成分鐘. 不過, 經我網上搵過既意見, 有部份人讚成用 ORM, 因為除左可以提升 program 既 simplicity 之外, man hour 係 develop 同 maintain 傳統 program 既時間同金錢, 應該遠比用 ORM Tool 既速度慢而買既 hardware cost 高, 所以如果要比較傳統既 SQL 方法同 ORM 黎講, 應該係後者會比較好. dtsv.dtse_post_28_permalink = 'http://wongkalun.idv.hk/2008/03/17/obect-relational-mapping-%e7%94%a8%e5%be%8c%e6%84%9f/'; dtsv.dtse_post_28_title = 'Object Relational Mapping [...]]]></description>
		<wfw:commentRss>http://wongkalun.idv.hk/2008/03/17/obect-relational-mapping-%e7%94%a8%e5%be%8c%e6%84%9f/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

