<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          前端如何主導ddd架構(gòu)落地(上)

          共 1703字,需瀏覽 4分鐘

           ·

          2022-12-03 08:39

          這是一個兼具技術(shù)和劇情的故事。

          首先,我其實是一個全棧

          我當初給我司投簡歷的時候,其實是想做前端經(jīng)理的。面試官看著簡歷:做過四年的.net,接著就一直做前端開發(fā)了,典型的全棧嘛,所以,做技術(shù)經(jīng)理(公司后端是java)似乎也沒啥毛病。然后,我就成了一個掛著技術(shù)經(jīng)理這張皮的前端經(jīng)理。在非互聯(lián)網(wǎng)公司,做一個技術(shù)經(jīng)理真的要求不高,你只需要會點前后端,有過實際管理經(jīng)驗就能上了。在小公司,業(yè)務實現(xiàn)只需要在前端展示頁面內(nèi)容,一般就是一個大屏加上業(yè)務系統(tǒng),就完了。對后端的要求就更低了,只要能查到我要的數(shù)據(jù)就行,那基本上普通的三層架構(gòu)就能解決問題,最多就是在接口調(diào)用那里加一個線程池來緩解一下不到100個的并發(fā)壓力。

          我之所以說我是個假技術(shù)經(jīng)理,是因為項目來了,我除了在前期進行前后端任務分解、計劃編寫之后,后面基本上不再過問后端的開發(fā)細節(jié)了。我要么就是跟蹤進度,要么就是搞搞前端疑難雜癥。

          很顯然,在大公司里,我這個技術(shù)經(jīng)理是不稱職的,后端的代碼好壞只能看程序員的人品,直到ddd架構(gòu)需要落地的事來了,事情有了“轉(zhuǎn)機”。。

          由于公司在上云項目,后端服務全部微服務化,然后必須按照ddd架構(gòu)進行后端改造。當時,我手上就有一個業(yè)務線正在上云,上級部門檢查我們的后端不符合ddd要求,然后輸出了問題文檔,比如耦合嚴重、sql過于復雜等等此類問題,作為“稱職”的技術(shù)經(jīng)理,我當然要把問題拋出來,讓后端去修改了。當時,我估摸著改10天應該差不多了吧!結(jié)果整整3個月過去了,后端的代碼檢查仍然不通過,這才有了標題說的這個故事:前端如何主導ddd架構(gòu)!

          為什么要用ddd

          ddd中文名叫領域驅(qū)動設計,英文名叫Domain-DrivenDesign。在中臺遍地開花的日子,ddd就像那道光,指引著中臺的設計和落地。像阿里、騰訊等很多大公司都有完整成熟的中臺產(chǎn)品,比較有代表性的有:阿里云數(shù)據(jù)中臺、騰訊技術(shù)中臺及字節(jié)的直播中臺等。中臺的落地過程中,微服務的設計與拆分是一個最大的痛點。微服務優(yōu)點很明顯,缺點也很明顯,如果設計地不好,幾個微服務之間相互勾連,我完成一件事可能要啟動多個微服務,才能保證業(yè)務實現(xiàn)。這明顯與微服務“高內(nèi)聚低耦合”的設計初心相違背。ddd的就是基于類似這樣的背景而產(chǎn)生的一種設計思想。

          以我的理解,ddd就是要求對系統(tǒng)的業(yè)務模型進行拆分,然后基于此模型映射到微服務代碼模型。在代碼模型中,分為四層架構(gòu):基礎層、領域?qū)印脤蛹坝脩艚涌趯印_@里面最關(guān)鍵的就是領域?qū)樱^領域,顧名思義,在一個領域內(nèi),我可以盡情玩耍,能滿足我的各種需求就足夠了。更復雜的需求,就在應用層里進行編排實現(xiàn)就行,然后在接口層對外暴露接口。基礎層主要是包含一些通用技術(shù)、數(shù)據(jù)庫服務及配置資源服務等內(nèi)容。ddd的四層架構(gòu)可以參考如下這張圖:

          本文對ddd不做深入分析,作為一個假技術(shù)經(jīng)理,直到后端的代碼在三個月之后仍然不能通過規(guī)范檢查時,我實際上才真正明白,這個項目必須嚴格按照ddd架構(gòu)落地,我這才去翻閱了一些資料。簡單說吧,上面就是我掌握的關(guān)于ddd的所有內(nèi)容。我基本就是靠著這三板斧把這個事給辦了。

          為什么是前端指導ddd架構(gòu)

          這一段就是后端開發(fā)看了會流淚的情節(jié)了。我曾對我上司說過,給我一個月,我能成為一個很好的java。他的回復是,如果是我,我會在準備得差不多了才會提出來。我理解他的意思,畢竟公司對人員是有定位的,你一個前端經(jīng)理,天天不研究前端問題,摸魚搞后端,成何體統(tǒng)?問題是技術(shù)本身并沒有難度,但是有時間成本,如果你想從前端轉(zhuǎn)后端,第一步是得準備一個環(huán)境吧。單單是這一步,就能讓很多開發(fā)望而卻步。其實在程序員這個行當里久了,你就會發(fā)現(xiàn),很多牛逼的人,其實并沒有強大到你追不上的地步,他其實就是行動力強了一點點而已。

          是的,前面我已經(jīng)提到,在我決定來搞明白什么是ddd時,我這個項目的兩個后端,兩個java開發(fā),搞ddd已經(jīng)搞了三個多月了。因為他們已經(jīng)陷入了如何拆分復雜sql的怪圈之中不能自拔。現(xiàn)在,輪到前端來主導ddd架構(gòu)了。。(未完待續(xù))

          更多精彩,請看下回分解--  前端如何主導ddd架構(gòu)落地(下)

          • 參考資料:極客時間《DDD實戰(zhàn)課》


          瀏覽 93
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  A片网站在线免费观看 | 变态另类TS人妖一区二区 | 在线精品一区豆花 | 色婷婷在线资源 | 五月六月婷婷 |