兩年前偶然接觸了DDD（領域驅動設計），雖然讀過了這方面最重要的兩本著做，可是一直沒有機會真正實踐，在本身作過的業務架構設計項目中曾想作過一次嘗試，但最終沒能進行下去，究其緣由，我想，應該是這種設計不能是「一我的的戰鬥」吧，須要上下游共同研究。微信
DDD誕生的時間不短了，可是一直沒有很流行，一方面是因其設計方法較爲複雜，通常設計人員難以短期掌握；另外一方面，也是一直沒有特殊的理由讓你們有足夠的動力去擁抱這一比較「困難」的方法，直到微服務的興起，兩者的自然契合讓DDD被愈來愈多的大公司重視，好比NETFLIX和阿里。今年終於參加了一次「領域驅動設計中國峯會」，近距離聽聽實踐者的親身感覺，峯會的熱烈、外地慕名者的踊躍，充分體現了DDD的上升勢頭。架構
DDD是一種從業務架構直通技術架構的設計方式，這也是我當時作業務架構時對這一方法產生興趣的緣由。可是因其在技術設計方面的內容較爲深刻，因此對多數非技術類的產品經理或者業務架構人員而言，不是很容易掌握。與多數架構設計同樣，DDD也不是一個會產生「統一結果」的設計方式，儘管有統一的術語，並把在業務和技術、技術和技術之間創建「統一語言」做爲目標，可是做爲一種有較強開放性的智力活動，設計老是很難產生如同數學般的定理，同一方法在不一樣人手中會產生不一樣結果。一位嘉賓在分享中回答個人問題時，也坦言，當他們決定採用DDD時，僅就基本設計理念，在架構師團隊中就花了三個多月時間才造成接近一致的見解，然後在實施中又是經過每一輪迭代不斷與開發團隊磨合，直到你們逐漸對方法和設計都達成一致的認知。正如多位嘉賓提到的，包括業務架構在內的架構設計，都不可能一蹴而就，必須反覆溝通、修正，直到造成共識爲止。微服務
今年有多場演講都涉及業務架構這個主題，並有一場是業務架構專場，我特別去感覺了下在這種大型會議上可貴一見的同行，她講了從業務架構的「畫布分析法」到DDD的過渡方法。「畫布分析法」跟我以前用過的「戰略房子」很是接近，應該說只是沒有「戰略」這個屋頂部分，其餘內容徹底一致。可以有這樣一個專場，可見DDD方法體系對業務部分的重視，的確，沒有一個好的業務架構，也很難有一套的好的業務系統。如同一位嘉賓開的玩笑同樣，業務說要風險管理系統，技術立馬搬出Hadoop、Hive等殺器，業務說打住，我要的只是黑名單。oop
好多技術人員以爲戰略是一個比較空、離本身很遠的東西，其實否則，戰略必須落實到業務中，沒有落實到業務流程中的戰略是不可落地、不會被真正執行的，而落到流程中的，天然就會再考慮落到系統中。若是技術人員，尤爲是架構師，對公司戰略不瞭解，那怎麼判斷本身設計的系統是符合業務發展要求的呢？若是隻是聽業務人員要什麼給什麼，那這種N次傳手後衰減了無數的信息，是否能開發出一個真有業務價值的系統呢？沒有對公司戰略、業務架構的共識，就不可能產生跟公司總體行爲配套的業務系統。如今是提倡業務與技術深度融合的時代，若是不像DDD方法那樣，業務人員、領域專家、架構師、技術人員坐在一塊兒達成共識，而靠「鐵路警察、各管一段」的方式傳遞需求，產生的必然是「破債纏身」的系統。而更進一步的，技術人員要主動走到業務人員中間去開展交流、獲取需求、解決問題，業務架構這個技術堆兒裏偏業務的品種，應該多綻開一些生命力。爭取把業務人員甚至你的老闆都培養出架構思惟，公司才能在真正把IT跟業務融合起來，不妨再想一想《鳳凰項目》吧。spa
但願DDD方法可以帶動業務架構再來上一波。.net
本文分享自微信公衆號 - 曉談巖說（）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。架構設計