2010-05-31 43 views
2

我正在嘗試製作管理系統的域模型。我有以下樣的人在這個系統:域模型中的專業化層次

employee 
manager 
top mananger 

我決定來定義User,從那裏EmployeeManagerTop Manager將專門從。 現在,我不知道我應該選擇什麼樣的專業化層次。 我無法通過以下方式之間作出決定:

alt text

alt text

這可能是最好,爲什麼?

作爲一個很長時間的編碼器,每次我試圖做一個領域模型時,我都必須反對試圖思考我將如何編碼這個想法。根據我的理解,我不應該在領域模型中考慮這些問題,只能在對象關係中考慮這些問題。在這裏我不必考慮代碼重複或任何這些細節,所以我不能真正選擇其中的任何選項。

感謝

編輯:

我會更明確一點:這是管理員工的休假計劃的程序。通過此計劃,員工可以選擇一年中的一組假期天數。然後,經理可能會批准或不批准每一位員工,並且在最後一天,高級經理應批准或不批准經理的決定。這是我程序的所有用戶應該能夠做到的。沒有其他任務。

回答

2

這主要歸結爲您如何定義術語的問題。基本的問題是,在任何可能的情況下,是否可以用經理代替一名員工 - 並且不知道正在建模的工作場所規則,對此不可能說某種方式。

一個普遍的概念是,至少在某個點上,一個經理應該能夠完成他的任何一個下屬的工作(至少一個級別,很可能是兩個或三個) 。

另一方面,在一些有很多工會驅動規則的地方,情況可能並非如此。即使一個人完全有能力完成工作,規則也可以阻止他完全替代該職位。在某些情況下,這來自認證要求等(例如,管理人員可能有資格完成工作,但所需的認證已失效)或來自工會規則之類的事情(例如,曾經因爲我的朋友而遭到譴責,他從公司店裏拿着手電筒和電池回到他的實驗室,而不是讓工會材料處理員爲他做這件事)。

+0

我認爲這裏的情況是,一個員工完成一組不同的任務,而不是一個經理。兩種類型的經理(經理和高級經理)事實上都是一樣的,只有在不同層面上:經理批准或詆譭員工選擇的休假,而高層管理者可以批准或摒棄經理人的決定。 – 2010-05-31 04:10:10

+0

@devoured:我會考慮是否那些不能像經理批准他的直屬下屬的決定那樣被整合。 – 2010-05-31 04:31:46

2

在現實生活中,經理們也是員工。所以這肯定只是一個日益專業化的連鎖:

User -> Employee -> Manager -> Top Manager 

編輯

「這是管理員工的休假 計劃的程序。」

在你們公司做經理們計劃度假嗎?他們確實如此。同樣當然你不打算建立一個單獨的應用程序來管理它。所以你真正需要的是:

User -> Requester 
    -> Approver 

每個用戶將成爲一個批准鏈中的請求者。 (您可能需要爲CEO特別安排)。另外一些用戶將成爲一個或多個連鎖店的批准者。最終的批准人可能會根據申請人的等級而有所不同:CEO不願意批准幹部職員的休假安排。

您需要一些規則來強制誰可以成爲任何給定請求者假期的審批者。除非你有一個非常扁平的組織,否則你會發現你有一個等級的工人和管理者。例如,一個團隊負責人或一個工頭 - 在其他方面是「工人」而不是「經理」的人 - 可能在連鎖店。你也可能需要考慮組織的其他方面。例如,如果員工希望將下一年的休假轉移到可能需要人力資源部門批准的人員,通常沒有任何員工的管理責任。

編輯2

好了,所以我們正在建模的規則,而不是一個真實的場景任意設置。

讓我們來看看。每個用戶適合單個類別,通過這些任務定義:

  • 員工可以要求離開
  • 經理可以批准或拒絕休假請求
  • 高層管理者可以接受或顛覆的批准或拒絕

經理和最高管理者沒有共同的行爲。因此,第一個模型是正確的。

+0

我不相信他們,因爲員工將完成與經理完全不同的工作。管理者會管理員工,而員工則會做「骯髒的工作」。管理者從不做「骯髒的工作」。或者我錯了?回到這個特定的案例,我會更加明確:這是一個管理員工休假計劃的計劃。通過此計劃,員工可以選擇一年中的一組假期天數。然後,經理可能會爲每一位員工批准或不批准,並且在最後一天結束時,高級管理人員應該批准或解散經理的決定。 – 2010-05-31 03:49:45

+0

雖然你強調一個好點,但在計劃規範中沒有任何說明管理者會休假,所以他們不會有(至少在這個計劃中)。 – 2010-05-31 04:21:49

+0

是的,我也認爲他們沒有共同之處。 – 2010-05-31 04:55:14

1

我會模仿這些作爲演員。它們不是系統的領域,而是系統的用戶。你會用「想要糖果的學校孩子」,「想要吸菸的學校孩子的父母」,「業務員」等來模擬一家商店的庫存系統嗎?雖然只有商店經理(演員)可以在沒有收據的情況下退款,但系統級別的重要之處在於系統認可了店鋪經理的關鍵,而這正是軟件中的權限令牌,而不是演員所需的角色。

您描述的系統域是休假請求和用戶帳戶,某些用例意味着某些帳戶有權對假期請求執行某些狀態轉換。

將用戶/經理/員工建模爲角色和角色的不同之處在於,您可以專注於建模您需要投入系統的內容,因爲不必具有角色的層次結構 - 您可以開始使用抽象用例和系統實體級別,而不是演員。考慮'代碼如何工作'並不總是一個壞主意,至少在問'爲什麼要編碼這個區別'這個問題上。