都在it圈子混，為什麼有些人可以成為一流高手，有些人搞了10年研發還只能靠吃老本兒過日子。簡單來說，搞這行兒您得勤奮。特喜歡電影《霸王別姬》中的一句：「要想人前顯貴，您就得背後受罪」。這人吶，就得學會自已個兒成全自個兒。好多ddd初級玩家上來就特喜歡聊「聚合」啊、「框架」啊、「事件溯源」啊，劉震雲先生管這個叫「噴空」。其實他忘了乙個重要的事兒：人家之所以能成為高手，那憑得是台下幾年的「功夫」，靠得是「悟性」，不是光靠噴空得來的。這個圈子沒有傻人，痴人太少。
別人講ddd喜歡上來就告訴你各種概念，我上來就喜歡打擊您。所謂「良藥苦口」，不從根源找到自身問題你也沒法上公升至更高的維度對其它人實施降維打擊。「人為萬物之靈」，在ddd這門學問中，「人」的作用是第一位的。因為人是活的，技術是死的，業務是客觀的，能否操縱死的技術對客觀業務進行完美支撐靠得是有血有內有靈魂的您。面對這個花花世界的**，踏踏實實的坐下來鑽研一門學問，您哪知道後面有什麼好事兒等著呢？有這麼乙個理兒叫「士人有百折不回之真心，才有萬變不窮之秒用」，您琢磨琢磨是不是這個意思。
說了半天，想要鑽研ddd要應該如何修身呢？概括下來有三點，有圖有真相。這些事兒您都知道未必能做到，路長著呢，「積跬步才得以致千里」。
學會客觀的看待事物是研究ddd 所應持有的態度。看過無數文章，一提ddd尤其是在技術階段，一定是對標書上那套odd（物件驅動設計，就是「值型別」、「聚合根」那套）方式。咱們不評價其它人的想法，只談個人感受。我其實挺喜歡經典三層的，簡單且直觀；我也搞odd，拿出來成就感爆棚也挺能唬人。總體而言呢，兩者所用比例大概是7：3。這個選擇不是因為我不會玩兒「實體」、「聚合」，是因為沒必要。如果您接觸過ddd尤其是其戰術部分，我勸您一句：莫要拘泥於書上所定義的形式，過去管這叫「形勢主義」。odd僅僅是軟體的落地方式之一，寫面向過程的**不代表您的整體系統不是以ddd為指導設計的，這事兒得從巨集觀上看。再說了，ddd兩部分呢，戰略部分才是核心。所以說我勸您眼裡別只有某個具體的技術，站得高方能看得遠，這叫格局。
就odd本身而言，複雜且麻煩。就算是乙個微服務架構系統，也是由業務複雜度各異的服務或模組構成。您的團隊中，有初級、中級程式設計師，也有不是一般的戰士。讓適當的人以適當的開發方式做適當的功能模組（或服務），安排妥妥的。建個「資料字典」功能也考慮怎麼設計「聚合」，您不累嗎 ？
人都說「文人相輕」，其實程式設計師之間也好不到哪兒去兒，同水平人誰也看不上誰的東西。再說了，it技術這個東西吧，也沒乙個具體的衡量標準，從程式的結果上看其實也沒差個多少。兩者比拼的就是系統在上線後在可維護性與擴充套件性上面誰更高效。
總而言之，想學習ddd學問的您，要注意個人修養的鍛鍊，尤其要務實、客觀，莫要好高騖遠、人云亦云。微服務挺帥、devops也比較酷，不一定適合您。畢竟對於我輩之打工人，公司不是咱們家開的。花裡胡哨的後面，那是有成本作為代價的。
這一節講了個人修養，後面我們來分析分析為什麼大家都天天喊著「ddd很難」，下回見。
戲說領域驅動設計（三） 困境
我第一次捧起老艾那本 領域驅動設計 驚為天人。吾輩上下求索數年，這不正是終極之大道嗎？結果只三天熱乎勁兒，什麼玩意兒 是對這本書的最好評價。好好的一本書讓我 棄之如敝履 差點就 小舟從此逝,江海寄餘生 了。幾年過後讀了網上一些老baby寫的吐槽ddd的文章，幾乎視其為知音啊，那概括的真是精闢，絕對是...
戲說領域驅動設計（五） 子域
細心的您可能已經發現了乙個規律，ddd使用了一種由上至下的方式來指導系統的構建。第一層考慮如何把大的領域劃成多個小的子域，重要性不一樣，投入的人和錢肯定也不一樣 第二層考慮系統的架構方面，仍然是一類巨集觀的工作，不過其更加聚焦於如何把大的系統分成幾個物理子系統及子系統間的互動方式 如果非微服務架構，...
領域驅動設計系列 二 領域模型
領域驅動設計裡有很多東西，我們可以應用在各種各樣的開發模式裡，所以接下來說的一些東西，我們可以部分使用。說道領域驅動的領域，大家肯定就要開始說bounded context,聚合，聚合根，容易讓大家搞糊塗。我覺得先拋開這些概念，後面再來說如何設計聚合，先簡單來說。過去，我們在多層設計裡定義了很多mo...