開民宿的故事

假設我開了一間民宿，那麼對我來說，日常中對我來說最重要的一件事是收住宿費，因為有住宿費才能支持民宿營運，為了收住宿費，我需要知道房型費用、住宿天數，假設A住了兩天1000元房型，那麼我要收取2000元住宿費，此外為了經營熟客，我會給客人集點卡，每晚住宿就得到一點，集滿三點就可以換一晚住宿，我有空的時候，會做早餐給客人，每次收取50元早餐費

本篇重要名詞彼此關係和各自定義

Entity [ 關鍵業務資料＋關鍵業務規則]

→ Use Case [業務規則]

→ IO 模型

1. 業務邏規則＆ 業務資料
   簡述：
   業務規則就是任何賺取或節省商業資金的規則或程序，業務資料就是執行業務規則所需資料
   “關鍵” 業務規則，代表的是商業行為中最核心最重要的業務邏輯

   舉例：
   以民宿故事來說，收訂房費就是關鍵業務規則，收早餐費則是業務規則而已，房型費用、住宿天數則是關鍵業務資料

   特性：

   1. 業務規則，是生意的核心，即使不用軟體系統，依舊存在

2. Entity 實體
   簡述：
   在軟體系統中的物件，包含實作關鍵業務資料的方法和定義關鍵業務資料的屬性
   舉例：
   以民宿訂房官網來說，我有一個 Charge Entity 其中有 caculate() 計算住宿費方法 和 charge 房型費用的屬性

   特性：

   1. Entity 具有獨立性，不受資料庫、使用者介面、第三方框架影響

3. Use Case 使用案例

   簡述：
   明確定義和規範自動化運行的方式，以達到替組織賺錢省錢的目標，定義輸入、輸出和執行步驟
   舉例：
   熟客必須，在報到時候，主動出示集點卡，並由櫃檯人員驗證是否為本店集點卡，符合三點，當日住宿及折抵半價

   特性

   1. 定義使用者，輸入、輸出、產生涉及輸出之處理步驟
   2. use case 依賴 Entity ，所以 Entity 對 use case 一無所知且 Entity 層級高於 Use case
   3. use case 只描述應用程式特定業務規則，不在乎資料是怎麼輸入的，或輸出成什麼樣子