原创 DDD的演進

演進領域驅動架構的着手點: 1 避免領域模型出現貧血模型 2 保證領域模型的純粹性   避免貧血的領域模型   經典三層架構中 1 領域邏輯 在 業務邏輯層的service對象中 2 反映了領域概念的 領域對象 被定義爲Java Bea

原创 DDD對軟件複雜度的應對

表象: 規模與結構 導致 理解力障礙 變化 導致 預測能力問題   根因: 需求   DDD關注的焦點 在於 領域 以及 領域邏輯 原因: 軟件系統的本質: 給客戶提供具有業務價值的領域功能   需求分爲 業務需求:業務複雜度 技術需求:

原创 DDD各層次職責與協作關係

架構演進得到了 符合DDD思想的分層架構 是一種靜態邏輯劃分   實現業務用例時,各層之間是怎麼協作的?   辨別動態協作關係的方法: 從職責的角度入手,清楚地理解分層架構中每個層次的職責   案例: 電商系統的下訂單場景 在買家提交訂

原创 類內方法

除構造方法外,類中還可以有三類方法 實例方法、 .class 字節碼文件加載之後,實例方法並不會被分配方法人口地址 , 只有在對象創建之後纔會被分配方法人口地址 實例方法可以調用靜態變量和靜態方法 應儘量使用 類名名.靜態方法”來調用

原创 緩存數據一致性

主要參考自 美團點評 張韓文章: https://maimai.cn/article/detail?fid=1057432698&efid=vnXzd0cl0pDwUW6f6iMpGA&from=groupmessage 爲什麼會有緩存數

原创 分層架構基礎

爲什麼要將業務與基礎設施分開? 答:引起它們變化的原因不同 單一職能原則的體現   經典分層架構 最爲經典的就是三層架構以及領域驅動設計提出的四層架構。   經典三層架構: 用戶界面層(User Interface Layer)、業務邏輯

原创 辨別限界上下文的協作關係

1 是否存在關係 2 是何種關係 3 基於變化導致的影響來確定是否需要引入防腐層、開放主機服務等模式 4 發現協作關係有不合理之處,則需要反思之前我們識別出來的限界上下文是否合理。   限界上下文通信邊界對協作的影響 怎麼做:如何確定限界

原创 代碼模型的架構決策

代碼模型 體現了 代碼模塊的 結構層次 架構視圖中 代碼模型 作爲其中一個視圖 展現模塊的 劃分 定義運行時實體 與 執行視圖建立聯繫 ​ 代碼模型的設計可以分爲兩個層次,具體如下。 系統層次:設計整個軟件系統的代碼模型。 限界上下

原创 統一語言

統一語言 定義:需求分析的過程(系統目標、範圍、具體功能達成一致的過程)中提煉領域知識的產出物 意義:在統一語言的前提下可以尋找正確的領域概念,爲建立領域模型提供重要參考。 消除領域專家與團隊、以及團隊成員之間溝通的分歧與誤解   統一語

原创 限界上下文

限界上下文的 含義:用一個清晰可見的邊界(Bounded)將這個上下文(Context)勾勒出來 Context 表現了業務流程的場景片段 上下文(Context)其實是動態的業務流程被邊界(Bounded)靜態切分的產物。   上下文(

原创 控制軟件複雜度的原則

導致軟件系統變得複雜的成因是規模、結構與變化三要素   控制複雜度的原則:就需要對 規模、結構與變化 逐個擊破   規模 保證系統的小規模,分而治之,小即是美   在應對新需求時,不會直接去修改一個複雜的舊系統,而是通過添加新特性,然後對

原创 線程

創建方式 線程的創建有三種方式:繼承Thread,實現Runnable接口,利用Callable跟Future 繼承Thread (1)定義Thread類的子類,並重寫該類的run方法,該run方法的方法體就代表了線程要完成的任務。因此把

原创 反射的使用

Class對象 虛擬機在class文件的加載階段,把類信息保存在方法區數據結構中,並在Java堆中生成一個Class對象,作爲類信息的入口。   獲取Class對象一般有三種方式: 通過實例變量方式 代碼塊 Chec

原创 DDD基礎

是什麼:領域驅動設計是一種方法論:是針對軟件開發領域提出的一套系統與理論分析方法 是一種思維方式,也是一組優先任務 目的:降低或隱藏整個系統的業務複雜性,並使得系統具有更好的擴展性,應對紛繁多變的現實業務問題。 加速那些必須處理複雜領域的

原创 反射

Java 反射效率低主要原因是: 1 Method#invoke 方法會對參數做封裝和解封操作 2 需要檢查方法可見性 3 需要校驗參數 4 反射方法難以內聯 5 JIT 無法優化 代碼塊 public class Reflect {