架構
CRM/SFA應用很大程度不同于其它的OFBizBiz應用，OFBIZ應用設計為一組可以整合在一起適合各種商業(yè)活動的進程，CRM/SFA應用設計為支持角色/活動的全部活動在CRM應用中，這樣子，它將帶來與其它應用的很多不同點
1.CRM/SFA的商業(yè)邏輯粒度小于其它OFBiz，而且通常會調(diào)用很多其它應用中的action。如當創(chuàng)建一個帳戶時，CRM/SFA應用將調(diào)用另一個OFBiz服務創(chuàng)建Party、PartyGroup、PartyRole、PartyRelationship等等
2.在OFBiz其它應用中高度抽象的數(shù)據(jù)模型在這里表達成更傳統(tǒng)直觀的概念。示例，“Party”被表達成為account ,lead, contact, team, 或 team member, 它們擁有不同的用戶界面和業(yè)務邏輯。
3.OFBiz的“WorkEffort”面向用戶時表達為“Activity”,而且只是事件和業(yè)務可作為“Activity”,其它的 “WorkEffort”例如制造產(chǎn)品過程在CRM/SFA中不顯示出來。
4.它擁有PartyRelationship.securityGroupId定義多個參與者之間權限的不同的安全模型（示例，組成員A是否有權訪問B帳戶？）它使用了不同的安全方法（查看“Security Documentation”了解詳細信息）
用戶界面原則
CRM/SFA應用有一個不同于其它OFBiz應用的界面原則。簡單來說，此原則就是 建立一個容易讓用戶明白和使用的界面，好過讓用戶不停的思考如何使用。
示例，“work effort”是一個OFBiz中的a task, a project, an event, 或a manufacturing production step,在OFBiz的WorkEffort應用中讓用戶自己創(chuàng)建它時選擇對應的實例選項，而在這里，WorkEffort被分離在不同的人機界面上顯示各自的特性。
大多數(shù)使用者，不會想“我打算創(chuàng)建一個work effort在參與者X和Y之間”，他們通常想“我為參與者X和Y在明天上午建立一個約會”。這樣CRM/SFA應用提供創(chuàng)建約會界面并加入?yún)⑴c者X和Y，在此界面啟動約會及完成它。
所以這意味著有些在OFBiz中允許的操作在CRM/SFA界面中不再被允許。示例，在OFBiz創(chuàng)建一個“EVENT”類型的work effor時可把它關聯(lián)到貨運或產(chǎn)品制作過程。這些信息在OFBiz的work effort中是可見字段，盡管work effort在event中并無這些關聯(lián)字段。另一面，在CRM/SFA中界面看不到這些字段
這樣的功能減少帶來的是操作的易于理解，且也讓一些日常的操作減少不必要的步驟。
另一個UI原則是將很多分離的步驟合而為一個操作步驟。最好的例子是當你創(chuàng)建一個聯(lián)系人時，你可以在一個屏幕內(nèi)輸入所有聯(lián)系人信息，而系統(tǒng)會自動的根據(jù)信息創(chuàng)建參與者、聯(lián)系信息及關聯(lián)項，將很多分離在不同OFBiz中的應用合而為一。
最后，我們打算避免用戶點擊回退、向前去查看信息，所以太多數(shù)屏幕都把信息顯示在同一個屏幕里，而不是提供很多的信息標簽
編碼約定
另外，創(chuàng)建CRM/SFA應用，我們還有一些與其它不同的編碼約定：
1.強制要求將視圖與數(shù)據(jù)準備分離，我們限制視圖層如freemaker頁/XML只承擔展現(xiàn)數(shù)據(jù)功能。這樣意味著在form組件中不會存在”action”標簽。
2.在屏幕組件定義中，使用beanshell腳本比<entity-one> XML操作更好。
3.Minilang腳本在一個方法中不要超過十行。使用java來編寫復雜的商業(yè)邏輯。不要在minilang中使用<or>、<and>及計算。
4.保證代碼塊簡捷。一般的，如果你的方法超過兩百行，建議你考慮如何重構它。
5.為你的代碼加上注釋。描述你編碼的目的和結果，而不僅是你做了什么。示例，如果你編寫了如下代碼
invoiceId=null;
不要注釋寫成：//設置InvoiceId為null
而應該寫成：//invoiceId應該為空，否則服務不會創(chuàng)建一個新的發(fā)票
6.使用較長的變量/方法名稱，如：computeForecastParentPeriod，而不是一個很短無意義的名稱。
7.使用意指你所調(diào)用的實體對象的變量名，而不僅是一個縮略的變量名。 示例，如果你獲得一個orderItems集合，變量名不要僅叫做”item”——可以叫它們”orderItems”或”nextOrderItem”，諸如此類。如果你獲得一個OrderPaymentPreference實體，不要命名為“payments”，因為Payment實體同你命名的這個對象不是同一個東西。
8.在FTL、表單組件、beanshell和Java服務中使用java來幫助將復雜的邏輯進行分離。
9.將代碼分離在應用的不同目錄中，將表單、屏幕組件XML文檔放在widgets目錄中，將JAVA包放在src/目錄下，F(xiàn)TL放在webapp/crmsfa/，BSH腳本放在webapp/crmsfa/WEB-INF/actions/中…
10.在服務XML中加了相關注釋指出需注意的事項或此服務可能發(fā)生的意外
本文檔譯自opentaps v0.9 manual,本人翻譯,歡迎轉載,請注明出處.