給房仲經紀人使用的 B 端物件刊登平台，涵蓋 B 端物件、點數、會員與通知中心。經紀人以點數購買刊登、排序、物件置頂（關注焦點）等廣告方案，平台依付費權益決定物件在前台的曝光位置，讓公司能直接向房仲收取刊登與廣告費用；整個系統全部建置在雲端。

專案概述

一般人在房仲網站上看到的物件，背後都要有人「刊登」上去。這個專案做的是給房仲經紀人（B 端）使用的刊登平台：經紀人在平台上建立物件、上架到前台，並可以付費購買各種曝光方案，讓自己的物件被更多人看到。

對公司來說，這是一個直接向房仲收費的營收產品。收費項目包括：

物件刊登：依刊登件數與天數收費，件數買得越多、單價越低
物件排序：刊登期間每天自動更新數次，讓物件重新回到列表前面
物件置頂（關注焦點）：在列表最上方的重點曝光區塊固定顯示一段時間
刊登廣告：售屋、租屋各自有刊登與廣告方案

整個系統分成 B 端物件、點數、會員 三大核心，再加上負責推播的通知中心，並且全部建置在雲端。

收費方案

B 端刊登平台的收費方案頁面：左側為售屋刊登與廣告、租屋刊登與廣告、點數加值等選單；右側列出物件刊登 90 天（每筆每天自動更新 3 次）的 1、20、50、70 件方案與對應折扣，以及關注焦點 7 天（列表最置頂）方案

上圖是平台上的收費方案頁面，可以看到幾個設計重點：

方案 = 件數 × 天數 × 權益：例如「物件刊登 90 天，每筆每天自動更新 3 次」，購買 20 件、50 件、70 件分別有不同折扣，買越多日單價越低
廣告天數與使用期限分開計算：「關注焦點 7 天」是指置頂曝光 7 天，但購買後在 90 天內都可以挑一個時間使用，讓經紀人自己決定要把置頂用在哪個物件、哪個時機
方案之間有相依關係：關注焦點要搭配物件刊登使用——物件必須先在刊登中，才能被置頂
售屋與租屋分開：售屋、租屋的方案與價格各自獨立

這些規則都不是寫死在畫面上，而是由後端的方案設定決定：新增一個方案、調整價格與折扣、改變天數，只需要調整設定，不需要改程式。

系統架構

B 端刊登平台架構圖：房仲經紀人登入會員後，以點數購買方案取得權益；B 端物件以 CQRS + Event Sourcing 實作，寫入端刊登時檢查權益並寫入 MSSQL，讀取端 Elasticsearch 依付費權益決定排序，提供 C 端前台搜尋；新刊登與降價事件經由 RabbitMQ 送到通知中心，比對訂閱條件後推播給使用者

會員：全站統一認證

依 RESTful API 規範建立會員 API，管理經紀人與所屬店鋪的資料
串接 OAuth，B 端的所有網站共用同一套會員登入，經紀人登入一次就能在刊登後台、開發工具、店鋪管理之間切換
以 JWT 在各服務之間傳遞身分，每個 API 都能從 Token 中知道是哪位經紀人在操作，只能管理自己的物件、點數與方案

點數：所有收費的基礎

經紀人先儲值點數，再用點數購買各種方案。所有收費都走點數，讓「付款」和「購買方案」拆成兩件事：

加值：經紀人儲值後，點數進入自己的點數帳戶
扣點：購買方案時扣除對應點數，並取得方案的權益（件數、天數、使用期限）
退點：方案取消或異常時，依規則退回點數
交易紀錄：每一筆加值、扣點、退點都留下紀錄，帳戶餘額隨時可以由紀錄重新算出來、對得起來

點數牽涉到錢，所以每一次異動都不直接修改餘額，而是新增一筆交易紀錄，再由紀錄計算出目前的餘額；同一筆購買重複送出時，也只會扣一次點數。

B 端物件：CQRS + Event Sourcing

物件是整個平台最核心的資料，寫入和讀取的需求差異很大：

寫入端：經紀人刊登、修改、下架物件時，先檢查這位經紀人目前的權益—— 還有沒有剩餘的刊登件數、方案是否還在使用期限內——通過後才寫入。每一次變更都以事件的形式記錄下來（刊登、改價、下架、套用置頂……），物件的歷史可以完整追溯
讀取端：物件資料同步到 Elasticsearch，提供前台的搜尋與列表。物件的付費權益也一起寫進索引，前台查詢時直接依權益決定排序

排序與置頂：付費權益如何變成曝光

前台的物件列表，排序規則大致是：

關注焦點：購買置頂且仍在曝光期間的物件，固定顯示在列表最上方的重點區塊
自動更新：刊登方案中「每天自動更新 N 次」的物件，系統會在一天中定時更新它的排序時間，讓物件重新回到列表前段
其他條件：再依使用者選擇的條件（最新、價格、坪數等）排序

方案到期時，排程會把對應的權益從物件上移除，物件就回到一般排序。整個曝光邏輯都建立在 Elasticsearch 的索引欄位上，前台查詢不需要再回頭查方案與點數的資料。

通知中心：訂閱與推播

物件刊登之後，還要讓有興趣的人知道。通知中心負責物件的訂閱與推播：

使用者可以訂閱特定條件（區域、價格帶、社區）或特定物件
物件新刊登、降價時，寫入端發布事件到 RabbitMQ
通知中心訂閱這些事件，比對有哪些使用者的訂閱條件符合，再把通知推播出去

刊登服務只負責發布事件，不需要知道誰訂閱了什麼；之後要新增其他通知方式或通知類型，也只需要在通知中心擴充。

全面雲端化

整個平台——會員、點數、B 端物件、通知中心，以及背後的資料庫、Elasticsearch、 RabbitMQ——全部建置在雲端上，不依賴公司機房：

各服務各自部署、各自擴展，刊登尖峰時只需要擴充物件相關的服務
不需要自行維護實體主機，環境可以快速建立與複製
對外服務的可用性不再受限於單一機房

成果

公司得以依靠物件刊登、物件排序、關注焦點等方案，直接向房仲收取費用，成為穩定的營收來源
方案、價格、折扣都由設定決定，業務單位推出新方案不需要等工程排程
點數交易全部留有紀錄，帳務可以完整追溯
會員以 OAuth 統一認證，B 端所有網站共用同一套登入

使用技術

後端：C#、ASP.NET Core Web API、CQRS、Event Sourcing
資料：MSSQL、Elasticsearch
訊息：RabbitMQ
認證：OAuth、JWT
部署：雲端

B 端房仲刊登平台