現狀及問題

• 需求傳遞效率低，需求評審效率低，缺乏業務全景圖和全鏈路需求圖，小需求也需要眾人評審
• 重複建設較多，團隊協同效率低，根據康威定律系統架構和組織架構會互為影響
• 難以深耕，技術實現成本較高，疲於應付新需求，各端都難以深耕和精細化運作
• 運營支援效率低，介面重複開發，資料異構且成孤島，難以支撐業務及數字化運營
• 業務間缺乏隔離，QA測試成本較高，系統耦合封閉，很難拿出部分功能快速支援業務創新和試錯

新開發模式

• 需求結構化，提供通用描述語言，並對需求進行結構化管理
• 業務視覺化，業務具備視覺化能力，可表現出系統具備的業務能力
• 引擎架構，做到以不變應萬變，構建穩定業務核心
• 提效業務吞吐，從區域性技術開發效率提升變為提升全域性業務開發效率

核心關鍵詞：

• 平臺：概念開發框架，公共協作平臺
• 業務技術對映：DDD，程式碼結構化，標準對映
• 引擎式架構：抽象原子指令，構建執行引擎，涉及表達切面

DDD解決的問題

將業務描述統一語言，將業務描述語言和技術要素之間做互相對映，劃定需求界限上下文，不同研發團隊負責具體界限上下文之內的需求迭代，產生服務和具體功能模組。 界限上下文之內，以領域方式進行系統分層和物件職能分配，領域內包含：

• 介面層
• 應用服務層
• 領域模型層
• 基礎設施層

領域模型層：

• 值物件
• 實體
• 領域服務
• 聚合
• 領域事件
• 工廠
• 資源庫

業務描述和技術要素對映

業務組成：業務規則，業務流程，業務活動

業務規則： 對映的結果是規則的表達，Domain.Service，Entity.validator等校驗器，謂詞判斷等。

業務流程： 進行流程編排DSL，技術元件可以通過Builder工廠模式實現。

業務活動： 業務邏輯對映到領域模型，通過Entity，Value Object，Domain Service，Factory構造複雜物件，實現對資料和行為的對映。

引擎式架構

梳理並解決問題域，解空間。

將系統能力進行接入抽象，抽象為“資料物料”接入，資料物料包括：營銷資源，匹配策略，定製規則，管控策略等。 系統能力擴充套件抽象成介面或外掛擴充套件，比如新的營銷資源，新的匹配規則，展示層定製配置，協同營銷策略等都抽象為資料或者表示式。

通過資料，表示式，外掛（介面）完成整個營銷能力的接入，配置和擴充套件。 配置即資料，規則即資料，資源即資料。 系統不變的核心就是整個分層次的引擎系統，灌輸不同的資料就具備不同的能力。

平臺組成

• BDF開發框架
• 開放協作平臺

整個平臺由開放規範，業務概念抽象，BDF開發框架，開放協作平臺組成。

BDF開發框架：

解決程式碼結構化，業務視覺化，業務身份識別，業務隔離，監控，問題診斷等問題。

業務需求由多種業務能力編排而成。 業務能力由規則組合而成。 規則由資料+行為組合而成。 多種業務能力屬於一種角色。 針對於角色內的擴充套件定製擴充套件點。

業務視覺化分析定製能力 -> 自動生成需求PRD能力 -> 業務SDK自動生成能力 -> QA自動迴歸測試能力 -> 自動虛擬隔離部署能力 -> 自動資料業務運營能力

通過可拔插元件管理和對已有元件擴充套件實現開發擴充套件能力

RD根據SDK定製開發沉澱出新的業務元件，定製化SDK

解構口訣

• 語法和語義解耦
• 語義和執行解耦
• 執行和引擎解耦
• 引擎和平臺解耦
• 平臺和業務解耦
• 演算法