免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

前言

設(shè)計(jì)是把雙刃劍，沒(méi)有最好的，也沒(méi)有更好的，而是條條大路到杭州。同時(shí)不設(shè)計(jì)和過(guò)度設(shè)計(jì)都是有問(wèn)題的，恰到好處的設(shè)計(jì)才是我們追求的極致。

DDD（Domain-Driven Design，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）只是一個(gè)流派，談不上壓倒性優(yōu)勢(shì)，更不是完美無(wú)缺。 我更想跟大家分享的是我們是否關(guān)注設(shè)計(jì)本身，不管什么流派的設(shè)計(jì)，有設(shè)計(jì)就是好的。

從我看到的代碼上來(lái)講，阿里集團(tuán)內(nèi)部大部分代碼都不屬于
DDD
類型，有設(shè)計(jì)的也不多，更多的像“面條代碼”，從端上一條線殺到數(shù)據(jù)庫(kù)完成一個(gè)操作，僅有的一些設(shè)計(jì)集中在數(shù)據(jù)庫(kù)上。我們依靠強(qiáng)大的測(cè)試保證了軟件的外部質(zhì)量（向苦逼的測(cè)試們致敬），而內(nèi)部質(zhì)量在緊張的項(xiàng)目周期中屢屢得不到重視，陷入日復(fù)一日的技術(shù)負(fù)債中。

一直想寫(xiě)點(diǎn)什么喚起大家的設(shè)計(jì)意識(shí)，但不知道寫(xiě)點(diǎn)什么合適。去年轉(zhuǎn)到盒馬，有了更多的機(jī)會(huì)寫(xiě)代碼，可以從無(wú)到有去構(gòu)建一個(gè)系統(tǒng)。盒馬跟集團(tuán)大多數(shù)業(yè)務(wù)不同，盒馬的業(yè)務(wù)更面向 B 端，從供應(yīng)到配送鏈條，整體性很強(qiáng)，關(guān)系復(fù)雜，不整理清楚，誰(shuí)也搞不明白發(fā)生什么了。所以這里設(shè)計(jì)很重要，不設(shè)計(jì)的代碼今天不死也是拖到明天去死，不管我們?cè)诤旭R待多久，不能給未來(lái)的兄弟挖坑啊。在我負(fù)責(zé)的模塊里，我們完整地應(yīng)用了 DDD 的方式去完成整個(gè)系統(tǒng)，其中有我們自己的思考和改變，在這里我想給大家分享一下，他山之石可以攻玉，大家可以借鑒。

領(lǐng)域模型探討

1. 領(lǐng)域模型設(shè)計(jì)：基于數(shù)據(jù)庫(kù) vs 基于對(duì)象

設(shè)計(jì)上我們通常從兩種維度入手：

Data Modeling: 通過(guò)數(shù)據(jù)抽象系統(tǒng)關(guān)系，也就是數(shù)據(jù)庫(kù)設(shè)計(jì)

Object Modeling:
通過(guò)面向?qū)ο蠓绞匠橄笙到y(tǒng)關(guān)系，也就是面向?qū)ο笤O(shè)計(jì)大部分架構(gòu)師都是從 Data Modeling 開(kāi)始設(shè)計(jì)軟件系統(tǒng)，少部分人通過(guò) Object
Modeling 方式開(kāi)始設(shè)計(jì)軟件系統(tǒng)。這兩種建模方式并不互相沖突，都很重要，但從哪個(gè)方向開(kāi)始設(shè)計(jì)，對(duì)系統(tǒng)最終形態(tài)有很大的區(qū)別。

Data Model

領(lǐng)域模型（在這里叫數(shù)據(jù)模型）對(duì)所有軟件從業(yè)者來(lái)講都不是一個(gè)陌生的名詞，一個(gè)軟件產(chǎn)品的內(nèi)在質(zhì)量好壞可能被領(lǐng)域模型清晰與否所決定，好的領(lǐng)域模型可以讓產(chǎn)品結(jié)構(gòu)清楚、修改更方便、演進(jìn)成本更低。

在一個(gè)開(kāi)發(fā)團(tuán)隊(duì)里，架構(gòu)師很重要，他決定了軟件結(jié)構(gòu)，這個(gè)結(jié)構(gòu)決定了軟件未來(lái)的可讀性、可擴(kuò)展性和可演進(jìn)性。通常來(lái)說(shuō)架構(gòu)師設(shè)計(jì)領(lǐng)域模型，開(kāi)發(fā)人員基于這個(gè)領(lǐng)域模型進(jìn)行開(kāi)發(fā)。“領(lǐng)域模型”是個(gè)潮流名詞，如果拉回到 10 幾年前，這個(gè)模型我們叫“數(shù)據(jù)字典”，說(shuō)白了，領(lǐng)域模型就是數(shù)據(jù)庫(kù)設(shè)計(jì)。

架構(gòu)師們?cè)谛枨笥懻摰倪^(guò)程中不停地演進(jìn)更新這個(gè)數(shù)據(jù)字典，有些設(shè)計(jì)師會(huì)把這些字典寫(xiě)成
SQL 語(yǔ)句，這些語(yǔ)句形成了產(chǎn)品 /
項(xiàng)目數(shù)據(jù)庫(kù)的發(fā)育史，就像人類胚胎發(fā)育：一個(gè)細(xì)胞（一個(gè)表），多個(gè)細(xì)胞（多個(gè)表），長(zhǎng)出尾巴（設(shè)計(jì)有問(wèn)題），又把尾巴縮掉（更新設(shè)計(jì)），最后哇哇落地（上線）。

傳統(tǒng)項(xiàng)目中，架構(gòu)師交給開(kāi)發(fā)的一般是一本厚厚的概要設(shè)計(jì)文檔，里面除了密密麻麻的文字就是分好了域的數(shù)據(jù)庫(kù)表設(shè)計(jì)。言下之意：數(shù)據(jù)庫(kù)設(shè)計(jì)是根本，一切開(kāi)發(fā)圍繞著這本數(shù)據(jù)字典展開(kāi)，形成類似于下邊的架構(gòu)圖：

在 service 層通過(guò)我們非常喜歡的 manager 去 manage
大部分的邏輯，POJO（后文失血模型會(huì)講到）作為數(shù)據(jù)在 manager 手（上帝之手）里不停地變換和組合，service
層在這里是一個(gè)巨大的加工工廠（很重的一層），圍繞著數(shù)據(jù)庫(kù)這份 DNA，完成業(yè)務(wù)邏輯。

舉個(gè)不恰當(dāng)?shù)睦樱杭偃缬懈赣H和兒子這兩個(gè)表，生成的 POJO 應(yīng)該是：

public class Father{…}

public class Son{

private String fatherId;//son 表里有 fatherId 作為 Father 表 id 外鍵

public String getFatherId(){

}

……

}

這時(shí)候兒子犯了點(diǎn)什么錯(cuò)，老爸非常不爽地扇了兒子一個(gè)耳光，老爸手疼，兒子臉疼。Manager 通常這么做：

public class SomeManager{

public void fatherSlapSon(Father father, Son son){

}

}

這里，manager 充當(dāng)了上帝的角色，扇個(gè)耳光都得他老人家?guī)兔Α?/p>

Object Model

2004
年，Eric Evans 發(fā)表了《Domain-Driven Design –Tackling Complexity in the Heart
of Software》（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)），簡(jiǎn)稱 Evans DDD，先在這里給大家推薦這本書(shū)，書(shū)里對(duì)領(lǐng)域驅(qū)動(dòng)做了開(kāi)創(chuàng)性的理論闡述。

在聊到 DDD 的時(shí)候，我經(jīng)常會(huì)做一個(gè)假設(shè)：假設(shè)你的機(jī)器內(nèi)存無(wú)限大，永遠(yuǎn)不宕機(jī)，在這個(gè)前提下，我們是不需要持久化數(shù)據(jù)的，也就是我們可以不需要數(shù)據(jù)庫(kù)，那么你將會(huì)怎么設(shè)計(jì)你的軟件？這就是我們說(shuō)的 Persistence Ignorance：持久化無(wú)關(guān)設(shè)計(jì)。

沒(méi)了數(shù)據(jù)庫(kù)，領(lǐng)域模型就要基于程序本身來(lái)設(shè)計(jì)了，熱愛(ài)設(shè)計(jì)模式的同學(xué)們可以在這里大顯身手。在面向過(guò)程、面向函數(shù)、面向?qū)ο蟮木幊陶Z(yǔ)言中，面向?qū)ο鬅o(wú)疑是領(lǐng)域建模最佳方式。

類與表有點(diǎn)像，但不少人認(rèn)為表和類就是對(duì)應(yīng)的，行 row 和對(duì)象 object 就是對(duì)應(yīng)的，我個(gè)人強(qiáng)烈不認(rèn)同這種等同關(guān)系，這種認(rèn)知直接導(dǎo)致了軟件設(shè)計(jì)變得沒(méi)有意義。

類和表有以下幾個(gè)顯著區(qū)別，這些區(qū)別對(duì)領(lǐng)域建模的表達(dá)豐富度有顯著的差別，有了封裝、繼承和多態(tài)，我們對(duì)領(lǐng)域模型的表達(dá)要生動(dòng)得多，對(duì) SOLID 原則的遵守也會(huì)嚴(yán)謹(jǐn)很多：

引用：關(guān)系數(shù)據(jù)庫(kù)表表示多對(duì)多的關(guān)系是用第三張表來(lái)實(shí)現(xiàn)，這個(gè)領(lǐng)域模型表示不具象化， 業(yè)務(wù)同學(xué)看不懂。

封裝：類可以設(shè)計(jì)方法，數(shù)據(jù)并不能完整地表達(dá)領(lǐng)域模型，數(shù)據(jù)表可以知道一個(gè)人的三維，但并不知道“一個(gè)人是可以跑的”。

繼承、多態(tài)：類可以多態(tài)，數(shù)據(jù)上無(wú)法識(shí)別人與豬除了三維數(shù)據(jù)還有行為的區(qū)別，數(shù)據(jù)表不知道“一個(gè)人跑起來(lái)和一頭豬跑起來(lái)是不一樣的”。

再看看老子生氣扇兒子的例子：

public class Father{

// 教訓(xùn)兒子是自己的事情，并不需要?jiǎng)e人幫忙，上帝也不行

public void slapSon(Son son){

}

}

根據(jù)這個(gè)思路，慢慢地，我們?cè)诿嫦驅(qū)ο蟮氖澜缋镌O(shè)計(jì)了栩栩如生的領(lǐng)域模型，service
層就是基于這些模型做的業(yè)務(wù)操作（它變薄了，很多動(dòng)作交給了 domain objects 去處理）：領(lǐng)域模型并不完成業(yè)務(wù)，每個(gè) domain
object 都是完成屬于自己應(yīng)有的行為（single responsibility），就如同人跑這個(gè)動(dòng)作，person.run
是一個(gè)與業(yè)務(wù)無(wú)關(guān)的行為，但這個(gè)時(shí)候 manager 或者 service 在調(diào)用 some person.run 的時(shí)候可以完成 100
米比賽這個(gè)業(yè)務(wù)，也可以完成跑去送外賣這個(gè)業(yè)務(wù)。這樣的話形成了類似于下邊的架構(gòu)圖：

我們回到剛才的假設(shè)，現(xiàn)在把假設(shè)去掉，沒(méi)有誰(shuí)的機(jī)器是內(nèi)存無(wú)限大，永遠(yuǎn)不宕機(jī)的，那么我們需要數(shù)據(jù)庫(kù)，但數(shù)據(jù)庫(kù)的職責(zé)不再承載領(lǐng)域模型這個(gè)沉重的包袱了，數(shù)據(jù)庫(kù)回歸 persistence 的本質(zhì)，完成以下兩個(gè)事情：

存：將對(duì)象數(shù)據(jù)持久化到存儲(chǔ)介質(zhì)中。

取：高效地把數(shù)據(jù)查詢返回到內(nèi)存中。

由于不再承載領(lǐng)域建模這個(gè)特性，數(shù)據(jù)庫(kù)的設(shè)計(jì)可以變得天馬行空，任何可以加速存儲(chǔ)和搜索的手段都可以用上，我們可以用
column 數(shù)據(jù)庫(kù)，可以用 document
數(shù)據(jù)庫(kù)，可以設(shè)計(jì)非常精巧的中間表去完成大數(shù)據(jù)的查詢?？傊?dāng)?shù)據(jù)庫(kù)設(shè)計(jì)要做的事情就是盡可能高效存取，而不是完美表達(dá)領(lǐng)域模型（此言論有點(diǎn)反動(dòng)，大家看看就好），這樣我們?cè)倏纯醇軜?gòu)圖：

這里我想跟大家強(qiáng)調(diào)的是：

領(lǐng)域模型是用于領(lǐng)域操作的，當(dāng)然也可以用于查詢（read），不過(guò)這個(gè)查詢是有代價(jià)的。在這個(gè)前提下，一個(gè)
aggregate 可能內(nèi)含了若干數(shù)據(jù)，這些數(shù)據(jù)除了類似于 getById
這種方式，不適用多樣化查詢（query），領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)也不是為多樣化查詢?cè)O(shè)計(jì)的。

查詢是基于數(shù)據(jù)庫(kù)的，所有的復(fù)雜變態(tài)查詢其實(shí)都應(yīng)該繞過(guò) Domain 層，直接與數(shù)據(jù)庫(kù)打交道。

再精簡(jiǎn)一下：領(lǐng)域操作 ->objects，數(shù)據(jù)查詢 ->table rows

2. 領(lǐng)域模型：失血、貧血、充血

失血、貧血、充血和脹血模型應(yīng)該是老馬提出的（此老馬非馬老師，是 Martin Fowler），講述的是基于領(lǐng)域模型的豐滿程度下如何定義一個(gè)模型，有點(diǎn)像：瘦、中等、健壯和胖。脹血（胖）模型太胖，在這里我們不做討論。

失血模型：基于數(shù)據(jù)庫(kù)的領(lǐng)域設(shè)計(jì)方式其實(shí)就是典型的失血模型，以
Java 為例，POJO 只有簡(jiǎn)單的基于 field 的 setter、getter 方法，POJO 之間的關(guān)系隱藏在對(duì)象的某些 ID
里，由外面的 manager 解釋，比如 son.fatherId，Son 并不知道他跟 Father 有關(guān)系，但 manager 會(huì)通過(guò)
son.fatherId 得到一個(gè) Father。

貧血模型：兒子不知道自己的父親是誰(shuí)是不對(duì)的，不能每次都通過(guò)中間機(jī)構(gòu)（Manager）驗(yàn) DNA(son.fatherId) 來(lái)找爸爸，領(lǐng)域模型可以更豐富一點(diǎn)，給 son 這個(gè)類修改一下：

public class Son{

private Father father;

public Father getFather(){return this.father;}

}

Son 這個(gè)類變得豐富起來(lái)了，但還有一個(gè)小小的不方便，就是通過(guò) Father 無(wú)法獲得 Son，爸爸怎么可以不知道兒子是誰(shuí)？這樣我們?cè)俳o Father 添加這個(gè)屬性：

public class Father{

private Son son;

private Son getSon(){return this.son;}

}

現(xiàn)在看著兩個(gè)類就豐滿多了，這也就是我們要說(shuō)的貧血模型，在這個(gè)模型下家庭還算完美，父子相認(rèn)。然而仔細(xì)研究這兩個(gè)類我們會(huì)發(fā)現(xiàn)一點(diǎn)問(wèn)題：通常一個(gè) object 是通過(guò)一個(gè) repository（數(shù)據(jù)庫(kù)查詢），或者 factory（內(nèi)存新建）得到的:

Son someSon = sonRepo.getById(12345);

這個(gè)方法可以將一個(gè)
son object 從數(shù)據(jù)庫(kù)里取出來(lái)，為了構(gòu)建完整的 son 對(duì)象，sonRepo 里需要一個(gè) fatherRepo 來(lái)構(gòu)建一個(gè)
father 去賦值 son.father。而 fatherRepo 在構(gòu)建一個(gè)完整 father 的時(shí)候又需要 sonRepo 去構(gòu)建一個(gè)
son 來(lái)賦值
father.son。這形成了一個(gè)無(wú)向有環(huán)圈，這個(gè)循環(huán)調(diào)用問(wèn)題是可以解決的，但為了解決這個(gè)問(wèn)題，領(lǐng)域模型會(huì)變得有些惡心和將就。有向無(wú)環(huán)才是我們的設(shè)計(jì)目標(biāo)，為了防止這個(gè)循環(huán)調(diào)用，我們是否可以在
Father 和 Son 這兩個(gè)類里省略掉一個(gè)引用？修改一下 Father 這個(gè)類：

public class Father{

//private Son son; 刪除這個(gè)引用

private SonRepository sonRepo;// 添加一個(gè) Son 的 repo

private getSon(){return sonRepo.getByFatherId(this.id);}

}

這樣在構(gòu)造 Father 的時(shí)候就不會(huì)再構(gòu)造一個(gè) Son 了，但代價(jià)是我們?cè)?Father 這個(gè)類里引入了一個(gè) SonRepository，也就是我們?cè)谝粋€(gè) domain 對(duì)象里引用了一個(gè)持久化操作，這就是我們說(shuō)的充血模型。

充血模型：充血模型的存在讓
domain object
失去了血統(tǒng)的純正性，他不再是一個(gè)純的內(nèi)存對(duì)象，這個(gè)對(duì)象里埋藏了一個(gè)對(duì)數(shù)據(jù)庫(kù)的操作，這對(duì)測(cè)試是不友好的，我們不應(yīng)該在做快速單元測(cè)試的時(shí)候連接數(shù)據(jù)庫(kù)，這個(gè)問(wèn)題我們稍后來(lái)講。為保證模型的完整性，充血模型在有些情況下是必然存在的，比如在一個(gè)盒馬門店里可以售賣好幾千個(gè)商品，每個(gè)商品有好幾百個(gè)屬性。如果我在構(gòu)建一個(gè)店的時(shí)候把所有商品都拿出來(lái)，這個(gè)效率就太差了：

public class Shop{

//private List products; 這個(gè)商品列表在構(gòu)建時(shí)太大了

private ProductRepository productRepo;

public List getProducts(){

}

}

3. 領(lǐng)域模型：依賴注入

簡(jiǎn)單說(shuō)一說(shuō)依賴注入：

依賴注入在
runtime 是一個(gè) singleton 對(duì)象，只有在 spring 掃描范圍內(nèi)的對(duì)象（@Component）才能通過(guò)
annotation（@Autowired）用上依賴注入，通過(guò) new 出來(lái)的對(duì)象是無(wú)法通過(guò) annotation 得到注入的。

個(gè)人推薦構(gòu)造器依賴注入，這種情況下測(cè)試友好，對(duì)象構(gòu)造完整性好，顯式地告訴你必須 mock/stub 哪個(gè)對(duì)象。

說(shuō)完依賴注入我們?cè)倏磩偛诺某溲Ｐ停?/p>

public class Father{

private SonRepository sonRepo;

private Son getSon(){return sonRepo.getByFatherId(this.id);}

public Father(SonRepository sonRepo){this.sonRepo = sonRepo;}

}

新建一個(gè)
Father 的時(shí)候需要賦值一個(gè) SonRepository，這顯然在寫(xiě)代碼的時(shí)候是非常讓人惱火的，那么我們是否可以通過(guò)依賴注入的方式把
SonRepository 注入進(jìn)去呢？Father 在這里不可能是一個(gè) singleton 對(duì)象，它可能在兩個(gè)場(chǎng)景下被 new
出來(lái)：新建、查詢，從 Father 的構(gòu)造過(guò)程，SonRepository
是無(wú)法注入的。這時(shí)工廠模式就顯示出其意義了（很多人認(rèn)為工廠模式就是一個(gè)擺設(shè)）：

@Component

public class FatherFactory{

private SonRepository sonRepo;

@Autowired

public FatherFactory(SonRepository sonRepo){}

public Father createFather(){

}

}

由于 FatheFactory 是系統(tǒng)生成的 singleton 對(duì)象，SonRepository 自然可以注入到 Factory 里，newFather 方法隱藏了這個(gè)注入的 sonRepo，這樣 new 一個(gè) Father 對(duì)象就變干凈了。

4. 領(lǐng)域模型：測(cè)試友好

失血模型和貧血模型是天然測(cè)試友好的（其實(shí)失血模型也沒(méi)啥好測(cè)試的），因?yàn)樗麄兌际羌儍?nèi)存對(duì)象。但實(shí)際應(yīng)用中充血模型是存在的，要不就是把
domain 對(duì)象拆散，變得稍微不那么優(yōu)雅（當(dāng)然可以，貧血和充血的戰(zhàn)爭(zhēng)從來(lái)就沒(méi)有斷過(guò)）。那么在充血模型下，對(duì)象里帶上了
persisitence 特性，這就對(duì)數(shù)據(jù)庫(kù)有了依賴，mock/stub 掉這些依賴是高效單元化測(cè)試的基本要求，我們?cè)倏?Father
這個(gè)例子：

public class Father{

private SonRepository sonRepo;//=new SonRepository() 這里不能構(gòu)造

private getSon(){return sonRepo.getByFatherId(this.id);}

// 放到構(gòu)造函數(shù)里

public Father(SonRepository sonRepo){this.sonRepo = sonRepo;}

}

把 SonRepository 放到構(gòu)造函數(shù)的意義就是為了測(cè)試的友好性，通過(guò) mock/stub 這個(gè) Repository，單元測(cè)試就可以順利完成。

5. 領(lǐng)域模型：盒馬模式下 repository 的實(shí)現(xiàn)方式

按照 object domain 的思路，領(lǐng)域模型存在于內(nèi)存對(duì)象里，這些對(duì)象最終都要落到數(shù)據(jù)庫(kù)，由于擺脫了領(lǐng)域模型的束縛，數(shù)據(jù)庫(kù)設(shè)計(jì)是靈活多變的。在盒馬，domain object 是怎么進(jìn)入到數(shù)據(jù)庫(kù)的呢。

在盒馬，我們?cè)O(shè)計(jì)了 Tunnel 這個(gè)獨(dú)特的接口，通過(guò)這個(gè)接口我們可以實(shí)現(xiàn)對(duì) domain
對(duì)象在不同類型數(shù)據(jù)庫(kù)的存取。Repository 并沒(méi)有直接進(jìn)行持久化工作，而是將 domain 對(duì)象轉(zhuǎn)換成 POJO 交給 Tunnel
去做持久化工作，Tunnel 具體可以在任何包實(shí)現(xiàn)，這樣，部署上，domain 領(lǐng)域模型（domain
objects+repositories）和持久化 (Tunnels) 完全的分開(kāi)，domain 包成為了單純的內(nèi)存對(duì)象集。

6. 領(lǐng)域模型：部署架構(gòu)

盒馬業(yè)務(wù)具有很強(qiáng)的整體性：從供應(yīng)商采購(gòu)，到商品快遞到用戶手上，對(duì)象之間關(guān)系是比較明確的，原則上可以采用一個(gè)大而全的領(lǐng)域模型，也可以運(yùn)用 boundedContext 方式拆分子域，并在交接處處理好數(shù)據(jù)傳送，這里引用老馬的一幅圖：

我個(gè)人傾向于大 domain 的做法，我傾向（所以實(shí)際情況不是這樣的）的部署結(jié)構(gòu)是:

結(jié)語(yǔ)

盒馬在架構(gòu)設(shè)計(jì)上還在做更多的探索，在 2B+
互聯(lián)網(wǎng)的嶄新業(yè)務(wù)模式下，有很多可以深入探討的細(xì)節(jié)。DDD
在盒馬已經(jīng)邁出了堅(jiān)實(shí)的第一步，并且在業(yè)務(wù)擴(kuò)展性和系統(tǒng)穩(wěn)定性上經(jīng)受了實(shí)戰(zhàn)的考驗(yàn)?；诨ヂ?lián)網(wǎng)分布式的工作流引擎（Noble），完全互聯(lián)網(wǎng)的圖形繪制引擎（Ivy）都在精心打磨中，期待在未來(lái)的就幾個(gè)月里，盒馬工程師們給大家奉獻(xiàn)更多的設(shè)計(jì)作品。

作者介紹

張群輝，阿里盒馬架構(gòu)總監(jiān)。10 多年技術(shù)及管理實(shí)戰(zhàn)經(jīng)驗(yàn)，前阿里基礎(chǔ)機(jī)構(gòu)事業(yè)部工程效率總監(jiān)，長(zhǎng)期在一線指導(dǎo)大型復(fù)雜系統(tǒng)的架構(gòu)設(shè)計(jì)。DevOps、微服務(wù)架構(gòu)及領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)國(guó)內(nèi)最早的實(shí)踐者一員。崇尚實(shí)踐出真知，一直奮斗在技術(shù)一線。