問題一

Package name可能以下幾種
Com.cht.otp
Com.cht.otp.[功能]
Com.cht.otp.[model-name].[功能]

以上”[ ]”者為變數
因為同仁提到是否可以一眼看出此package中內容是什部分會比較好？還是反而不好？

回答一

以本案為例，我會簡單分成以下幾個
Com.cht.otp.external
Com.cht.otp.external.impl
Com.cht.otp.services
Com.cht.otp.services.impl
Com.cht.otp.model
Com.cht.otp.common
我的考量點在於專案複雜度＆溝通
專案的 Domain Model 是否有超過 35 個 classes ? 如果有，會考慮再細分，依照模組去區分
溝通是否困難，這是 package 命名的層面，能否從命名知道裡頭有哪些？能降低溝通難度，就是好的設計

問題二

View層

model

model

View層

View層

同仁提到, 每人開發的view層程式, 是否放在一起或分開 workspace, 如上圖A or B
個別說法 : 針對上圖A and B
A：彼此可以分開,未來不會彼此影響, 每人的implement方式可以不同
B: 可以彼此share共通部分

A

B

回答二

這問題我上周有提到，但當天沒有達成共識
如果是我，我會依照市場區隔去分不同的 web 工作區
一般客戶/企業用戶所使用的介面／流程是否雷同？ 如果都一樣，這會是一個網站 如果布希望一般客戶看到企業用戶的頁面，那就分成兩個網站
後端管理介面 for 客服
後端管理介面 for 管理者
這樣區分的原因？
日後維護容易，不管是移植或者改版都會比較容易找到要修正的項目
如果單一程式有問題，不會蔓延到其他 web
當然，這樣做會有網頁共用的問題
請思考，共用網頁是否能獨立成另一個工作區？

困擾

由domain model來考慮create DB schema時, 是否目前負責各開發功能的同仁,先就目前分配到的功能來設計class, 看要存取哪些資料,然後去create DB tables. 不過下個cycle時,可能覺得此tables的欄位不足,所以又要alter table來增加新的欄位…..請問如此作法是正確的嗎？

回答三

僅從物件導向的層面去思考
如果需要調整 ORM 就調整
實務做法(一)
利用 hibernate 自動找出 ORM 有差異的部分
由 hibernate 產生 alert 語法，交給 dba 查驗
確認後，到資料庫當中執行 alert 即可
這部分的程式請參照我第二天上課的範例
另一個實務做法是，自己 local 建測試 db，確認程式都完成(測試過)後，才執行實務做法(一)