今天晚上喝了幾兩65°的紅星二鍋頭,坐在沙發上回想了下我這苦逼的程序員人生,從程序員到高級工程師的成長過程。想了想主題,今天就寫篇《關于架構師那些事》的文章吧。
所有架構師都不是自帶光環,都是是從程序員->工程師,然后跟對一個好的領導或者好的項目開始學習框架,然后結合現有的知識一步一步磨煉成就了現在架構師的光環,從來就沒有一步登天的人才,都是從埋坑到填坑的過程中走過來的。
我曾經參與了很多項目的架構搭建及技術框架的選型,利用現在主流的框架搭建過平臺,也利用一些開源的平臺做過一些開發,其中走過的坑只有自己知道,那叫一個“爽”,包括:
多個tomcat分布式部署如何共享session,自己也寫過比較復雜的功能然后封裝成組件給程序員調用,例如權限控制、自定義報表組件、打印組件、憑證組件等。隨著現在技術的不斷成熟,不同階梯的程序員也越來越多,怎樣既能在提高開發效率的前提下,又能節省企業的成本,成為了不少科技公司管理的一大難題,特別是剛開始創業的公司。所以我們在拿到項目需要架構之前,要先了解項目的業務和模式,今天跟大家分享下我的一些經驗。
就暫時列這么多吧(酒勁上來了),可以根據自己的經驗和業務知識擴大下范圍,也可以利用一些現有的快速開發平臺然后再搭配組裝,所有的架構和選型都沒有對與錯,只有適合自己就是最好的。
快速開發平臺,就是可以使得開發更為快速的開發平臺。當開發平臺產生之后,雖然減少了編程人員大量的編程時間,但是很多開發平臺的效果并不是很理想,比如說某些開發平臺比較復雜、難以掌握;有的開發平臺通用性比較差;有的開發平臺在時間上并沒有得到改善;還有的依然還是需要寫很多代碼等等。這些問題的存在促使開發者不斷的摸索、不斷的改進,到最后越做越成熟,以致于現在市面上出現的大部分開發平臺效率都非常高,他們改善了以往的產品存在的缺陷,使得開發過程比以往更簡潔、編寫代碼更少、開發效率越來越高。我也整理了一些開源的平臺的資料,如下:
GitHub地址:https://github.com/thinkgem/jeesite
在線演示
JeeSite 是一個 Java EE 企業級快速開發平臺,基于經典技術組合(Spring Boot、Spring MVC、Apache Shiro、MyBatis、Beetl、Bootstrap、AdminLTE)采用經典開發模式,讓初學者能夠更快的入門并投入到團隊開發中去。在線代碼生成功能,包括核心模塊如:組織機構、角色用戶、菜單及按鈕授權、數據權限、系統參數、內容管理、工作流等。采用松耦合設計;界面無刷新,一鍵換膚;眾多賬號安全設置,密碼策略;在線定時任務配置;支持集群,支持SAAS;支持多數據源。
技術選型
JeeSite演示demo
官網地址:http://www.itttm.com/
IT榻榻米是一款java輕量級智能快速開發平臺,可以幫助您解決項目中90%的重復工作,讓您更多關注業務邏輯。由于本身輕量級特性,可根據自身需求二次開發想要的功能。
IT榻榻米演示demo
IT榻榻米套餐
官網地址:http://www.javafast.cn/
JavaFast演示demo
官網地址:http://www.jeecg.org/
演示地址:http://demo.jeecg.org/loginController.do?login
JEECG (J2EE Code Generation)是一款基于代碼生成器的免費開源的快速開發平臺。使用JEECG可以簡單快速地開發出企業級的Web應用系統。
隨著WEB UI框架(EasyUi/Jquery UI/Ext)等的逐漸成熟,系統界面逐漸實現統一化,代碼生成器也可以生成統一規范的界面!代碼生成+手工MERGE半智能開發將是新的趨勢,單表數據模型和一對多數據模型的增刪改查功能直接生成使用,可節省50%工作量,快速提高開發效率!
Java編程有很多重復機械代碼,生成器可以幫助解決50%的重復工作,讓開發更多關注業務邏輯,從而實現代碼生成+手工merge的半智能開發!JEECG智能框架可以有效解決信息孤島問題,生成統一代碼、統一規范、統一設計思路,使你能在這個平臺上,快速開發出高效高質量代碼,縮短項目開發周期。
平臺亮點
平臺架構
Jeecg演示demo1
Jeecg演示demo2
官網地址:http://www.eova.cn/
技術亮點
EOVA演示demo
官網地址:http://bsdn.org/projects/dorado7
演示地址:http://bsdn.org/projects/dorado7/deploy/sample-center/com.bstek.dorado.sample.Main.d
Dorado Presentation Middleware(即Dorado展現中間件,以下簡稱Dorado)致力于輔助Web應用中表現層的開發過程。Dorado主要可以為您帶來如下兩方面的使用價值:
Dorado Presentation Middleware產品包含3個主要的功能部分:Web客戶端、服務端引擎、IDE集成開發工具。(見下面插圖)
主要功能特點
1. 全新的Web客戶端
Dorado7提供了全新打造的Web客戶端,這包括全新的基礎運行框架和全新的控件庫。較之Dorado的前作,新的Web客戶端將帶來如下的增強:
2. 立體數據模型
“立體數據模型”因其相對于平面數據模型(二維數據模型)而得名。即指Dorado7推翻了Dorado前作中以DataSet為媒介、以二維表形式對于展現數據進行封裝和管理的設計思路。 Dorado7不再局限數據必須以二維表結構與DataSet對接,而是可以支持非常自由的數據形式。并且也不再提供專用的數據封裝對象。 這些變化使得展現層中的數據更加純粹、更加貼切真實的業務含義。自然,也使開發變得更加便利、更加生動。
“立體數據模型”是Dorado7相對于前作最重要的概念變化,也是Dorado7最為核心的設計思想。 以上的寥寥數語并不足以闡明這一抽象概念,請參考 Dorado7方法論 中關于“立體數據模型”的更多論述。
3. 沒有JSP的Web
秉承了Dorado產品的一貫風格,Dorado7仍以XML形式的視圖配置文件作為定義Web界面的主要手段。 不過,在Dorado7中這里的視圖配置文件被賦予了更多的內涵,視圖配置文件已經可以完整的描述Web界面的所有特性,JSP不再是Dorado7的必選項。 在大多數情況下,直接訪問一個視圖配置文件就可以得到一個功能完整的Web界面。
可能很多開發人員對于此特性會感到一絲不安,出于某些技術人員習慣以及頁面需求等原因,開發人員可能仍然需要以HTML形式來實現頁面的布局。 Dorado7同樣對此種使用方式提供了完善的支持。開發者可以很方便的使用JSP、Velocity或者其他類似的技術來為視圖配置文件定義布局方式。 并且,新的開發方式讓美工人員與開發人員的合作變得更為可行和便利。以JSP為例,Dorado7不再引入繁多的Taglib標簽庫,而是以純HTML方式的占位符來輔助Web頁面的布局。
4. 智能方法適配
“智能方法適配”是指允許開發人員盡可能按照自己的意愿、業務的需要來定義他們的業務方法,然后由Dorado引擎自動根據場景、參數名、參數類型等因素來判斷應當怎樣調用該業務方法。 “智能方法適配”是Dorado7提供的一個非常有特色的功能,提供此功能的主要目的是盡量減少開發人員所需要掌握的Dorado API,讓業務方法的代碼更加“業務化”,更加易于閱讀。
通過“智能方法適配”也可以很好的體驗出Dorado7所提倡的“基于約定而非配置”進行開發的理念。在實際的應用場景中大部分實現了Dorado前端的功能中可能并不需要引入任何Dorado的API。
5. 擴展和重用
為提高Dorado7產品的擴展性和可重用性我們在Dorado7中提供了很多新的特性,這些特性主要包括:
6. Client Edition
Dorado7提供Dorado7 Client Edition這樣一個特性的產品打包方式,Dorado7 Client Edition中只包含了Dorado7 Presentation Middleware中的Web客戶端部分(即Javascript和CSS的部分)。
發布此版本的目的是為了滿足各種Web項目中前端界面增強的需求。這里提到的Web項目包括基于JEE的Web項目和其他非基于JEE的Web項目,如.Net、PHP等,其定位類似于Ext。 Dorado7 Client Edition從一個側面體現出了Dorado7產品在設計上的封裝度和靈活性。
7. 不僅僅是展現中間件
雖然Dorado7的主要功能都是圍繞展現層這一主題展開的,可是我們認為Dorado7連同配套的SampleCenter提供給用戶的并不僅僅是對Web應用展現層的簡單補充。 通過Dorado7即相關的示例所承載的是一種非常實用的Web開發最佳實踐、一種新的開發模式。
因此可以說,使用Dorado您得到的可能并不是僅僅是對展現層的改良,也是對整體應用開發模式的一次度量和重鑄。
Dorado演示demo
地址:https://gitee.com/ldh123/maker
根據數據庫結構,按照用戶的要求,動態生成可執行代碼
生成的maven結構。spring mvc + spring + mybatis傳統接口
前端多技術: easyui, bootstrap + jsp, bootstrap + freemarker, javafx ui, flutter(android + ios)
技術亮點
代碼生成工具1
代碼生成工具2
代碼生成工具3
代碼生成工具4
代碼生成工具5
今天的分享就到這吧,我相信還有很多優質的資源,以后我也會慢慢的補上,如有知道的小伙伴也可以通過評論來分享。
點贊+轉發+評論,多多關注,以后有好的東西繼續分享給大家!
感謝大家支持!
今天晚上喝了幾兩65°的紅星二鍋頭,坐在沙發上回想了下我這苦逼的程序員人生,從程序員到高級工程師的成長過程。想了想主題,今天就寫篇《關于架構師那些事》的文章吧。
所有架構師都不是自帶光環,都是是從程序員->工程師,然后跟對一個好的領導或者好的項目開始學習框架,然后結合現有的知識一步一步磨煉成就了現在架構師的光環,從來就沒有一步登天的人才,都是從埋坑到填坑的過程中走過來的。
我曾經參與了很多項目的架構搭建及技術框架的選型,利用現在主流的框架搭建過平臺,也利用一些開源的平臺做過一些開發,其中走過的坑只有自己知道,那叫一個“爽”,包括:
多個tomcat分布式部署如何共享session,自己也寫過比較復雜的功能然后封裝成組件給程序員調用,例如權限控制、自定義報表組件、打印組件、憑證組件等。隨著現在技術的不斷成熟,不同階梯的程序員也越來越多,怎樣既能在提高開發效率的前提下,又能節省企業的成本,成為了不少科技公司管理的一大難題,特別是剛開始創業的公司。所以我們在拿到項目需要架構之前,要先了解項目的業務和模式,今天跟大家分享下我的一些經驗。
就暫時列這么多吧(酒勁上來了),可以根據自己的經驗和業務知識擴大下范圍,也可以利用一些現有的快速開發平臺然后再搭配組裝,所有的架構和選型都沒有對與錯,只有適合自己就是最好的。
快速開發平臺,就是可以使得開發更為快速的開發平臺。當開發平臺產生之后,雖然減少了編程人員大量的編程時間,但是很多開發平臺的效果并不是很理想,比如說某些開發平臺比較復雜、難以掌握;有的開發平臺通用性比較差;有的開發平臺在時間上并沒有得到改善;還有的依然還是需要寫很多代碼等等。這些問題的存在促使開發者不斷的摸索、不斷的改進,到最后越做越成熟,以致于現在市面上出現的大部分開發平臺效率都非常高,他們改善了以往的產品存在的缺陷,使得開發過程比以往更簡潔、編寫代碼更少、開發效率越來越高。我也整理了一些開源的平臺的資料,如下:
GitHub地址:https://github.com/thinkgem/jeesite
在線演示
JeeSite 是一個 Java EE 企業級快速開發平臺,基于經典技術組合(Spring Boot、Spring MVC、Apache Shiro、MyBatis、Beetl、Bootstrap、AdminLTE)采用經典開發模式,讓初學者能夠更快的入門并投入到團隊開發中去。在線代碼生成功能,包括核心模塊如:組織機構、角色用戶、菜單及按鈕授權、數據權限、系統參數、內容管理、工作流等。采用松耦合設計;界面無刷新,一鍵換膚;眾多賬號安全設置,密碼策略;在線定時任務配置;支持集群,支持SAAS;支持多數據源。
技術選型
JeeSite演示demo
官網地址:http://www.itttm.com/
IT榻榻米是一款java輕量級智能快速開發平臺,可以幫助您解決項目中90%的重復工作,讓您更多關注業務邏輯。由于本身輕量級特性,可根據自身需求二次開發想要的功能。
IT榻榻米演示demo
IT榻榻米套餐
官網地址:http://www.javafast.cn/
JavaFast演示demo
官網地址:http://www.jeecg.org/
演示地址:http://demo.jeecg.org/loginController.do?login
JEECG (J2EE Code Generation)是一款基于代碼生成器的免費開源的快速開發平臺。使用JEECG可以簡單快速地開發出企業級的Web應用系統。
隨著WEB UI框架(EasyUi/Jquery UI/Ext)等的逐漸成熟,系統界面逐漸實現統一化,代碼生成器也可以生成統一規范的界面!代碼生成+手工MERGE半智能開發將是新的趨勢,單表數據模型和一對多數據模型的增刪改查功能直接生成使用,可節省50%工作量,快速提高開發效率!
Java編程有很多重復機械代碼,生成器可以幫助解決50%的重復工作,讓開發更多關注業務邏輯,從而實現代碼生成+手工merge的半智能開發!JEECG智能框架可以有效解決信息孤島問題,生成統一代碼、統一規范、統一設計思路,使你能在這個平臺上,快速開發出高效高質量代碼,縮短項目開發周期。
平臺亮點
平臺架構
Jeecg演示demo1
Jeecg演示demo2
官網地址:http://www.eova.cn/
技術亮點
EOVA演示demo
官網地址:http://bsdn.org/projects/dorado7
演示地址:http://bsdn.org/projects/dorado7/deploy/sample-center/com.bstek.dorado.sample.Main.d
Dorado Presentation Middleware(即Dorado展現中間件,以下簡稱Dorado)致力于輔助Web應用中表現層的開發過程。Dorado主要可以為您帶來如下兩方面的使用價值:
Dorado Presentation Middleware產品包含3個主要的功能部分:Web客戶端、服務端引擎、IDE集成開發工具。(見下面插圖)
主要功能特點
1. 全新的Web客戶端
Dorado7提供了全新打造的Web客戶端,這包括全新的基礎運行框架和全新的控件庫。較之Dorado的前作,新的Web客戶端將帶來如下的增強:
2. 立體數據模型
“立體數據模型”因其相對于平面數據模型(二維數據模型)而得名。即指Dorado7推翻了Dorado前作中以DataSet為媒介、以二維表形式對于展現數據進行封裝和管理的設計思路。 Dorado7不再局限數據必須以二維表結構與DataSet對接,而是可以支持非常自由的數據形式。并且也不再提供專用的數據封裝對象。 這些變化使得展現層中的數據更加純粹、更加貼切真實的業務含義。自然,也使開發變得更加便利、更加生動。
“立體數據模型”是Dorado7相對于前作最重要的概念變化,也是Dorado7最為核心的設計思想。 以上的寥寥數語并不足以闡明這一抽象概念,請參考 Dorado7方法論 中關于“立體數據模型”的更多論述。
3. 沒有JSP的Web
秉承了Dorado產品的一貫風格,Dorado7仍以XML形式的視圖配置文件作為定義Web界面的主要手段。 不過,在Dorado7中這里的視圖配置文件被賦予了更多的內涵,視圖配置文件已經可以完整的描述Web界面的所有特性,JSP不再是Dorado7的必選項。 在大多數情況下,直接訪問一個視圖配置文件就可以得到一個功能完整的Web界面。
可能很多開發人員對于此特性會感到一絲不安,出于某些技術人員習慣以及頁面需求等原因,開發人員可能仍然需要以HTML形式來實現頁面的布局。 Dorado7同樣對此種使用方式提供了完善的支持。開發者可以很方便的使用JSP、Velocity或者其他類似的技術來為視圖配置文件定義布局方式。 并且,新的開發方式讓美工人員與開發人員的合作變得更為可行和便利。以JSP為例,Dorado7不再引入繁多的Taglib標簽庫,而是以純HTML方式的占位符來輔助Web頁面的布局。
4. 智能方法適配
“智能方法適配”是指允許開發人員盡可能按照自己的意愿、業務的需要來定義他們的業務方法,然后由Dorado引擎自動根據場景、參數名、參數類型等因素來判斷應當怎樣調用該業務方法。 “智能方法適配”是Dorado7提供的一個非常有特色的功能,提供此功能的主要目的是盡量減少開發人員所需要掌握的Dorado API,讓業務方法的代碼更加“業務化”,更加易于閱讀。
通過“智能方法適配”也可以很好的體驗出Dorado7所提倡的“基于約定而非配置”進行開發的理念。在實際的應用場景中大部分實現了Dorado前端的功能中可能并不需要引入任何Dorado的API。
5. 擴展和重用
為提高Dorado7產品的擴展性和可重用性我們在Dorado7中提供了很多新的特性,這些特性主要包括:
6. Client Edition
Dorado7提供Dorado7 Client Edition這樣一個特性的產品打包方式,Dorado7 Client Edition中只包含了Dorado7 Presentation Middleware中的Web客戶端部分(即Javascript和CSS的部分)。
發布此版本的目的是為了滿足各種Web項目中前端界面增強的需求。這里提到的Web項目包括基于JEE的Web項目和其他非基于JEE的Web項目,如.Net、PHP等,其定位類似于Ext。 Dorado7 Client Edition從一個側面體現出了Dorado7產品在設計上的封裝度和靈活性。
7. 不僅僅是展現中間件
雖然Dorado7的主要功能都是圍繞展現層這一主題展開的,可是我們認為Dorado7連同配套的SampleCenter提供給用戶的并不僅僅是對Web應用展現層的簡單補充。 通過Dorado7即相關的示例所承載的是一種非常實用的Web開發最佳實踐、一種新的開發模式。
因此可以說,使用Dorado您得到的可能并不是僅僅是對展現層的改良,也是對整體應用開發模式的一次度量和重鑄。
Dorado演示demo
地址:https://gitee.com/ldh123/maker
根據數據庫結構,按照用戶的要求,動態生成可執行代碼
生成的maven結構。spring mvc + spring + mybatis傳統接口
前端多技術: easyui, bootstrap + jsp, bootstrap + freemarker, javafx ui, flutter(android + ios)
技術亮點
代碼生成工具1
代碼生成工具2
代碼生成工具3
代碼生成工具4
代碼生成工具5
今天的分享就到這吧,我相信還有很多優質的資源,以后我也會慢慢的補上,如有知道的小伙伴也可以通過評論來分享。
點贊+轉發+評論,多多關注,以后有好的東西繼續分享給大家!
感謝大家支持!
平臺級項目開發中,選型和設計的重要性不言而喻,設計是軟件開發的先導,是對系統整體結構和功能的規劃和布局,在對醫療軟件業務的深刻理解之上,分析系統功能和業務流程,確定合適的技術架構和數據模型,定義接口規范,最終才能達成目標。
本文在技術選型上遵循的思路:用成熟的互聯網技術逐漸升級改造醫療中的傳統技術體系。互聯網技術比傳統技術有更有預期的發展性,更活躍的社團性,更先進的技術性。有時候選擇大于努力,充分利用已有的成熟輪子,選型得當后續活干得少。
代碼未動,設計先行,考慮篇幅的限制,本章節先概述選型原則和設計思路,實現內容在后續分章節說明。在建設思路中已經勾勒了技術框架的組成訴求,去掉具體的業務模塊部分,區域醫療平臺可以由4個通用部分組成。
平臺設計示意圖中的業務中臺包括業務開發框架和業務協同框架,數據中臺包括數倉體系和數據計算。這里的數據計算可以是常見的指標計算,標簽畫像的體系,成熟的機器學習體系,以及基于LLM構建的智能體系,共同支撐上層應用,以及醫療涉眾的使用。
醫療體系業務極為龐雜,分為院內系統和區域系統,院內系統按照國家衛計委2018年發布的《全國醫院信息化建設標準與規范(試行)》明確了醫院應用系統功能多達200多個,區域系統也不少,而且業務體系更加復雜。所以在設計醫療業務系統,需要根據業務場景和數據容量,選擇合適的開發框架。以前有很多醫療體系中有不少老系統基于net設計,但目前基于信創要求,會逐漸要求轉到自主可控/開源體系中。
業務系統可采用B/S架構,推薦采用Java生態體系來建設,以符合信創的要求。根據項目特點和規模采用單體結構或微服務結構,業務系統的開發框架可以自研腳手架,也可以根據成熟的開源產品進行產品化。現在基于Java的開發框架已經很成熟,也有成熟度較高的開源產品,直接選擇輪子就行。
如果是10年前,會推薦JeeSite,不過之后有部分代碼閉源了。所以現在做單體系統,可以是采用JSite,前端用的AdminLTE3 + Beetl3。如果感覺界面不怎么順手,可以用TopJUI前端框架來改造前端,基于高版本的jQuery EasyUI構建,適用于MES、ERP、HIS、CRM、OA等后臺系統的開發,而且界面已經脫離了EasyUI早期版本的經典式樣,有了明顯現代化的前端呈現。講到這里,為dorado前端框架感到惋惜,逐漸小眾化了。
單體系統的開發和部署都很方便,還可以搭建Svn/Git + Jenkins + Maven + SonarQube實現日構建系統,規范化開發。如果數據量在增大,可以采用讀寫分離以及分庫分表方式,再配置Redis進行熱點數據緩存提升系統性能,實現科室級的項目快速開發。如果這是大科室,訪問量有點多,可以部署個nginx進行粘性會話配置,實現系統的擴展。
在單體項目開發中,系統同樣可以分為前端和后端兩大部分,之所以保留這套體系是因為有很多科室級別的項目適合這種模式,而且架構簡單,適合熟練業務的開發人員在前后端開發時同步搞定,避免前后端拆開之后的人力損耗,而且借鑒dubbo + zookeeper體系,也可以拆分為前后端模式,實現急速開發和快速拆分。
代碼生成
中后臺的應用有大量基于表的常規增刪改查功能,可以采用代碼生成方式來生成前端和后端代碼,并符合預設的目錄和代碼規范結構,簡化開發工作量,以便快速部署。
從歷史的角度來看,代碼生成只是平臺業務開發體系的初級階段,基于模版按照預設規則生成圍繞表的增刪改查的通用代碼。在表單設計器/低代碼平臺中有了更高級方式,圍繞頁面表單生成相應邏輯的業務處理,設計者擁有更多的處理選項。
大江東去浪淘盡,曾經的單體架構也從小甜甜變成了牛夫人。基于現在的技術體系一般起手就是前后端分離的體系,前端從springMVC改成了Vue方式。不是說springMVC不行,而是在互聯網模式中從支持微服務體系、前端處理性能上看不是最合適的選擇。
采用這種開發模式下,人力成本會提升很多,醫療行業需要有多年經驗的業務開發人員參與其中,這些從遠古時代存留下來的業務開發人員熟悉的是單體技術棧,所以需要給他們配置一個前端開發人員。
如果是新建前后端分離的項目直接基于若依或者ruoyi-vue-pro作為基礎開發框架。推薦ruoyi-vue-pro,基礎框架的源碼全公開,設計良好的dependencies,基于Maven Module技術體系的常用業務功能擴展,集成了mybaits-plus,redis,mq,job等。另外ruoyi-vue-pro有springCloud的微服務版本,這樣方便業務的遷移和升級,只是要注意2個版本的module擴展不完全一樣,有細微區別。
1、項目結構
RuoYi-Vue 全新 Pro 版本,優化重構所有功能。基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + UniApp 微信小程序,支持 RBAC 動態權限、數據權限、SaaS 多租戶、Flowable 工作流、三方登錄、支付、短信、商城等功能。
有3種前端(越靠后顏值越高)
2、基于mybatis-flex的改造
原版ruoyi-vue-pro采用的是mybatis-plus作為orm,也是大多數腳手架的選擇,而且ruoyi-vue-pro在mybatis-plus的基礎上做了功能的提煉,抽象了一些常用的處理擴展作為抽象類方便使用。只是本人在使用中發現mybatis-flex提供了相似功能,并且有更通用的表達。下面的代碼就是對比效果,被注解的是mybatis-plus的擴展寫法,外面的是基于mybatis-flex寫法,純個人喜好。
@Mapper
public interface DeptMapper extends BaseMapper<DeptEntity> {
/*default List<DeptEntity> selectList(DeptListReqVO reqVO) {
return selectList(new LambdaQueryWrapperX<DeptEntity>()
.likeIfPresent(DeptEntity::getName, reqVO.getName())
.eqIfPresent(DeptEntity::getStatus, reqVO.getStatus()));
}*/
default List<DeptEntity> selectList(DeptListReqVO reqVO) {
return selectListByQuery( QueryWrapper.*create*()
.where(*DEPT_ENTITY*.NAME.like(reqVO.getName(), If::*notNull*))
.and(*DEPT_ENTITY*.STATUS.eq(reqVO.getStatus(), If::*notNull*)) );
}
/*default DeptEntity selectByParentIdAndName(Long parentId, String name) {
return selectOne(DeptEntity::getParentId, parentId, DeptEntity::getName, name);
}*/
default DeptEntity selectByParentIdAndName(Long parentId, String name) {
return selectOneByQuery(QueryWrapper.*create*()
.where(*DEPT_ENTITY*.PARENT_ID.eq(parentId)).and(*DEPT_ENTITY*.NAME.eq(name)));
}
/*default Long selectCountByParentId(Long parentId) {
return selectCount(DeptEntity::getParentId, parentId);
}*/
default Long selectCountByParentId(Long parentId) {
return selectCountByCondition(*DEPT_ENTITY*.PARENT_ID.eq(parentId));
}
}
采用前后端分離的項目,在業務使用量起來后,可以方便的遷移到微服務體系,尤其是alibaba的微服務體系。注意不是使用了微服務技術就是微服務平臺,有一些平臺雖然使用了微服務技術(SpringCloud 或ServiceComb),但只是實現了平臺本身架構是微服務的,而基于平臺二次開發的項目卻是單體的,要看平臺是否支持用戶自行擴展新的服務,且可以做到各服務之間的數據庫隔離,這樣做出來的項目才能稱得上微服務項目。
如果是采用ruoyi-vue-pro遷移到yudao-cloud,則更加方便,修改若干配置即可。如果在開發過程中沒有完全遵循微服務的劃分,有模塊之間的橫向api調用,則需要改成微服務模式。從功能上看和ruoyi-vue-pro基本類似,采用了alibaba的springCloud技術棧,增加了nacos,racketMQ,gateway等微服務基礎組件,同時把Job和事務改成了xxl-job和seata。
表單建模器
之前的代碼生成器的模式比較固定:要么從數據庫讀取已經定義好的表結構,工具生成實體部分代碼,或者是與框架強相關的不同層次的服務代碼;要么從配置文件,再反向生成數據庫代碼或者業務相關代碼;還有可能先定義實體類,再生成其他部分代碼。生成代碼之后,再拷貝到具體的代碼目錄。
在腳手架開發的基礎上,可以套用一個表單建模器,給后端開發人員提供一個快速界面開發的選項。基于表單建模器的開發:首先需要面向業務實現表單與實體模型之間的映射;其次運行時CRUD等與數據存儲相關操作,以及自動生成Id、自動添加審計日志、動態生成各種Sql語句、自動方法驗證等;然后可以定義與實體模型相關的動態方法執行,包括通用的增冊改查、分頁獲取數據等、執行自定義的Sql語句,還可以執行反射或者微服務調用定義等。
表單建模器能夠快速創建常規的業務模塊,可以把常規的業務功能做成模板,方便快速的創建業務模塊功能,選擇一個模板之后,會將模板對應的表單、子表單、子視圖、控件等所有自定義表單相關的定義全部自動創建出來,通過底層一套schema或DSL規范約束,生成JSON Schema;表單引擎通過加載JSON Schema渲染出表單。
不過要實現復雜的業務,單純的表單建模器不一定合適,本身醫療體系中面向患者的業務處理就很復雜,建模器的預設組件是覆蓋不了全部的醫療業務,強行匹配會適得其反。可以根據醫療業務的特點,把系統分為面向管理者的中后臺業務和面向患者的前臺業務,中后臺業務可以采用代碼生成、表單建模、或者低代碼平臺;而前臺業務還是需要前端開發人員根據實際業務去設計,根據業務特點去適配界面。
關于MIT協議
ruoyi-vue-pro和yudao-cloud采用的MIT協議,這是一種非常寬松的開源許可證,允許軟件在保留版權和許可證聲明的前提下,免費使用、復制、修改、合并、出版、分發、再授權和銷售等。該許可證適用于幾乎所有類型的軟件,包括商業軟件和專有軟件。
基于前后端分離或者微服務體系的腳手架,為醫療業務的實現提供了良好的基礎,只是有一類中后臺管理的業務,涉及大量的基于表的增刪改查業務和業務審批的業務,相對業務比較規范,可以采用低代碼平臺實現相應的業務,最終形成中后臺管理業務由低代碼平臺實現,復雜醫療業務由前后端/微服務腳手架實現,從而優化開發過程。
低代碼基礎架構可分為四個部分:由核心引擎(頁面、模型、工作流程、API編排)實現前端交互和業務編排的效果;可視化設計平臺對接開發者,實現平臺的表單設計和業務設定;平臺門戶提供通用的技術組件和常規業務模板;運營管理是平臺的基礎組件部分,對平臺的運行狀態進行檢測與管理。
開發者使用低代碼進行應用開發時,需要主數據設定,領域建模、頁面建模、服務編排、編譯出碼和部署運營等環節,其中頁面建模與服務編排是核心開發環節。
低代碼平臺中,主要由建模引擎和編排引擎支撐用戶的前端頁面操作。其中建模引擎支撐靜態模型構建,編排引擎支撐動態邏輯流轉。建模引擎支撐開發者在前端開發界面對應用程序的業務邏輯、數據結構和界面布局等進行設計和構建的行為,包含數據引擎、表單引擎、頁面引擎、領域建模引擎等。編排引擎支撐用戶可視化編排應用的數據表單流轉、自動化管理、服務調度,包含流程引擎、規則引擎、消息引擎、事件驅動引擎等。在建模引擎和編排引擎的共同作用下搭建完整的應用外殼。
現在業界也有了一些低代碼平臺,從開源角度看,成熟度高的是Jecloud。Jecloud分為社區版和商業版本。社區版提供了基礎的低代碼開發功能,以及OA審批功能。商業版多了括門戶展示套件,接口引擎,文檔套件,手機套件等擴展組件。
平臺功能架構分為:存儲層、平臺層、應用層、展現層。根據其不同層級劃分,開發和運維人員可根據不同的部署及實施方案構建出可用性強、擴展性高的應用。
Jecloud界面顏值高,做出來的效果和界面漂亮,在顏值即代表正義的當下,是一款不錯的開箱即用低代碼平臺。Jecloud是一套基于ServiceComb的微服務體系,特別適合信創平臺。Jecloud包括go和java部分,其中java部分開源,go是用來管理各個微服務的應用。
服務名稱 | 占用端口 | 用途 | 說明 |
mysql | 31306 | 數據服務 | 基礎服務 |
Redis | 31379 | 提供二級緩存等 | 基礎服務 |
openresty | 80 | 網關代理 | 基礎服務 |
comb | 30100/30103 | 注冊中心 | 基礎服務 |
apollo | 8070/8080/8090 | 配置中心 | 基礎服務 |
gateway | 3050 | 業務網關 | jecloud服務 |
meta | 3051 | 元數據 | jecloud服務 |
rbac | 3052 | 權限管理 | jecloud服務 |
connector | 3053/7010 | 連接器 | jecloud服務 |
workflow | 3054 | 工作流 | jecloud服務 |
demo | 3055 | demo | jecloud服務 |
document | 3056 | 文檔 | jecloud服務 |
message | 3057 | 消息 | jecloud服務 |
job | 3060 | job | jecloud服務 |
operator | 3061 | operator | jecloud管理(go) |
jinit | jinit | jecloud管理(go) |
前面闡述了4款開發框架的形態,也是開發平臺的發展過程,總有1款適合當前的業務開發。考慮到醫療體系的復雜和多樣性,推薦采用2套以上的框架,混合適配不同的場景開發,通過微服務做各個模塊的服務集成。
一種可能的場景是后臺管理型的業務可以采用低代碼平臺的模式;而面向患者的業務系統采用單體模式或者前后端模式;對于互聯網的惠民應用,在后臺服務的基礎上生成APP應用頁面或者微信小程序前端,就能涵蓋醫療業務體系的方方面面。
前文闡述了基于表的業務模塊開發,圍繞表單進行用戶的交互。還有一種是基于業務流程的開發,有2種業務流程:人-機交互的人工審批流程,機-機的自動處理流程(服務編排),Jecloud已經提供了基于Activiti7的審批型流程設計,但如果是基于微服務編排的業務邏輯,則需要服務編排引擎來支撐,兩者應用場景不一樣,所以設計思路也不同,需要區分對待。
服務編排的概念是微服務架構落地伴生而來,原本一次請求即可處理完成的業務,現在可能需要多次請求才能完成,為了降低前端邏輯的復雜性并提高前后端交互效率,BFF層應運而生。BFF作為前后端的代理層,提供了一個業務接口聚合層,其核心職責是為前端(PC、小程序、H5等)適配不同的業務場景,降低客戶端與業務端的耦合,前期通過硬編碼的方式來實現BFF層的需求,是最簡單最直接的方式。但隨著BFF層承接業務需求的增多,采取硬編碼方式容易產生編碼效率低、編碼細節難以規范、調試測試效率低等問題。
服務編排在統一規范的基礎上提供了業務邏輯的柔性設計,通過可視化設計快速的API的編排、調試、測試和上線。看上去服務編排和工作流引擎在形式上趨同,但兩者不一樣。在腳手架/低代碼平臺會提供類似Flowable 、Activiti、Camunda實現的OA審批工作流系統。這種工作流基于表單模式,通過擴展表或者表單表上添加輔組字段滿足業務的審批流轉,最終形成留痕記錄。這種模式都是人-機交互模式,而服務編排,更多的是機-機交互模式,強調的是服務(API)的有序調用。
微服務體系架構是一種前后端架構,在前后端之間添加中間層 (BFF:Backend For Frontend),以解決服務的匯聚和調用,把BFF加入在前后端架構之后,前端服務不再直接訪問后端微服務,而是通過 BFF 層進行訪問。從微服務的角度來看,由于有關 UI 邏輯的數據在 BFF 層進行了處理,減少前后端細顆粒微服務之間的相互調用。
BFF層的主要職責是組合使用后臺數據,稍微額外處理C端展示邏輯。可以參看前章的“基于tuxedo的API編排架構”的內容。綜上所述,采用BFF之后的開發邏輯:通過后臺工具查到原始數據,然后按照業務要求,把查到的原始數據封裝成API,再通過加工->組裝->適配成可以展示給前端的信息,最后發送給客戶端使用。這部分各個服務(API)的聚合工作主要由中間層的BFF API負責。
BFF API的處理也是有一定的業務邏輯,可以抽象為串行,并行,分支,匯聚等,包括多種服務接口的適配,可視化業務邏輯的設計,持久化保存需求,接口返回數據的裁剪、排序、格式化等操作,這些功能又可以映射為BPM的能力。所以最終支持BFF層運行的底層組件是BPM系統,提高提升微服務的復用度,降低編碼及編譯打包的等待時間,提高業務邏輯的快速交付能力。
可視化服務編排系統的核心功能都是對BFF日常需求及研發流程的抽象,從接口的調用方式、出入參的處理、接口異常情況的處理、服務的調試測試、服務的上線流程等幾個維度完成系統整體功能的設計。
A、實現思路
B、具體方案
C、BPM 系統選型
核心功能
當平臺積累了大量的后臺服務,如何有效使用是平臺設計的重要內容。服務首先要歸類,做好領域劃分,然后服務的命名和版本要規范,服務的出參和入參要考慮方便和實用。
A、平臺服務列表
B、服務類型
服務編排需要集成不同的第三方服務和內部服務,對于這些應用,接口和參數各不相同,考慮到方便服務的集成和內部服務的穩定,可以采用:外部接口=>轉換服務=>內部服務。
3、服務生命周期
微服務API的開發納入生命周期管理時,遵循一套開發,上線,下線,版本控制的管理。另外構建服務度量指標,通過日志和性能數據采集,監控服務運行監控狀態,并執行相應的限流,預警等管控策略,以確保微服務的持續健康,可靠和高效運行。
功能自洽的區域平臺的BFM-engine功能包括:
引擎的實現會涉及到flow-act-item,彼此有依賴關系,另外自身也有狀態變化,包括create-run-finish以及其他輔助狀態,所以如果自研引擎,需要構建一個3層狀態機模型。
對于3層狀態機,每層狀態機擁有自己的狀態變化,同時狀態變化可能會對其他狀態機產生影響。這里區分2種情況:
醫院/平臺的互聯互通為醫療健康大數據奠定了基礎;同時個性化診斷、疾病預測與輔助決策等各類醫療人工智能應用也在不斷涌現,醫療健康大數據的存儲和分析,需要有一套體系來管理,數據倉庫由此應運而生。
數據倉庫主要基于業務庫(OLTP)的數據以及第三方外部數據,通過采集清洗轉換后存儲在事實表中(事實+維度),實現系統的分析整理,支持各種分析方法,如聯機分析處理(OLAP)、數據挖掘等進行,進而支持決策支持系統、從而獲取有價值的信息。
數倉的建設需要根據數據采集量,指標計算的要求,周邊系統的匹配度,開發人員和運維人員的熟練程度來綜合考慮:
對于數據倉庫而言,無論怎么升級和變化,其設計目標是一致的,要求如下:
醫療體系平臺采用離線批處理方式能兼容最大多數的數據源,方便最大范圍的采集數據。在當前考慮關系型數據的情況下,數倉可以采用MPP 數據庫;在將來構建區域一統的多模態數據資源池的時候,可以考慮采用數據湖體系。
數據湖和數據倉庫作為大數據系統的兩條不同演進路線,各有適用范圍。數據倉庫適合處理結構化的數據可以實現良好的分析與處理,但對于非結構化數據、半結構化數據以及種類繁多、存儲量大的數據就需要數據湖來處理。
數據湖并不比數據倉庫在處理流程上多出了什么內容,更多的在于結構性的變化,2種處理方式,代表著兩種數據處理和服務模式,是數據技術領域的一次輪回。
數據倉庫的數據來源包括健康醫療大數據和其他行業數據來源。健康醫療大數據主要包括匯聚個體和各類醫療衛生業務機構數據所形成的全員人口、電子健康檔案、電子病歷、各垂直系統的業務管理數據等。其他行業數據來源包括教育、公安、民政、人力資源、社會保障、農業、安全監管、檢驗檢疫(氣象、保險監管、殘聯等相關部門及行業。
這些數據源來自各個醫療機構的業務庫,匯聚到交換中心的時候需要根據國家規范進行轉換清洗,形成區域一統的數據標準。也可以采用CDA作為數據來源進行采集,但一般來說,CDA的數據質量不如交換庫的采集模式。
數據標準是一套由管理制度、管控流程、技術工具共同組成的體系,通過這套體系來推廣和應用統一的數據定義、數據分類、紀律格式和轉換、編碼等來對數據的標準化,保障數據定義和使用的一致性、準確性和完整性的規范性約束。不限于如下標準:
在數據類規范中,通常著重對數據集、數據元、代碼以及數據交換接口的內容進行標準規范,從業務數據的角度,針對信息化建設的需要進行業務標準的編制。
在醫療體系中,數據模型貫穿整個業務領域和數據ETL的過程(ods-dwd-dws)。在業務領域中,醫學元數據結合領域信息模型可以被用來構建醫療數據的語義表達,從而更全面地表達和描述電子病歷。醫學元數據通常包括醫學數據的模式、定義和屬性,而領域信息模型則提供了關于特定醫學領域的知識和規則。
模型與數據庫
在基于醫院數據或區域平臺數據進行臨床科研和數據應用開發的過程中,即使在病人數量足夠的情況下,數據的可用性依然存在問題。目前影響醫療數據質量的原因如下:
A、數據治理的層級
在醫療體系中,將醫療數據治理按管理機構分為4類,本文更關注第2類。
1、醫院數據治理
醫院成立數據管理部門,完成流程和規范制訂、數據質量保證和質量控制、流程審批等工作,并對數據使用方和IT設施建設方進行管理,對其數據資產的管理和控制,支撐并保障數據被安全、高效地交換與使用。
2、區域數據治理
與醫院數據管理內容相似,但實施起來難度更復雜:
l 主數據管理和元數據管理的復雜度高:病人基礎數據是臨床醫療信息的主數據。區域數據來源于多家醫院,每家醫院病人用的身份標識不一樣,病人基礎信息也會有差異。需要通過統一標識來統一病人的主數據,并關聯病人在不同醫院的就診記錄。
l 數據安全性管理更嚴格:區域數據量比較大,病人的就診數據在時序上更完整,因此數據泄露帶來的嚴重性更大,區域對數據安全管理的要求更嚴格。
3、專科聯盟/專科醫聯體/專病中心的數據治理
專科聯盟一般由權威醫療機構牽頭,但是其牽頭單位并沒有行政權力,聯盟單位之間的協作共享完全是一種自愿的行為。因此,專科聯盟形式的醫聯體除了要解決區域醫聯體中碰到的技術問題外,還要解決數據共享后的利益分享問題,確保醫聯體每個成員能在數據共享活動中受益。
4、醫療標注數據與知識型數據治理
數據治理主要面向的對象是病人數據,但在醫院協作共享過程中,知識型數據也必不可少。在面向分析推理等智能應用,需要大量的標注數據,這些數據的管理和利用也屬于數據治理的范疇。
標注數據主要是針對電子病歷文本、影像等非結構化數據進行實體、屬性、關系等標注得到的數據,標注數據的質量對訓練深度學習或神經網絡模型起著決定性作用。為了實現對標注數據的治理,應該針對不同粒度的實體建立一套完整的標注規范,對標注過程的各要素進行規范化管理,并對標注結果進行交叉驗證等。
B、數據治理的內容
醫療數據治理工具平臺應包含數據存儲子系統、元數據管理子系統、主數據管理子系統、數據質量管控子系統以及患者數據脫敏工具等。
1、元數據管理
目前醫院信息系統中存在數據模式描述文檔不全、系統之間數據關聯不清晰、系統值域標準不統一等問題,這為數據集成造成了困難。在區域層面,這些問題更嚴重。因此,需要通過元數據管理獲取業務系統中數據的含義,輔助數據理解,增加分析的敏捷性。元數據管理可以提高數據的可訪問性、一致性及可用性,為多種來源數據的整合搭建了橋梁。
與其他領域相比,醫療領域的元數據規范相對比較成熟,參看《國家衛生計生委辦公廳關于印發住院病案首頁數據填寫質量規范(暫行)和住院病案首頁數據質量管理與控制指標(2016版)的通知》(國衛辦醫發〔2016〕24號)、《病歷書寫規范》(衛醫政發〔2010〕11號)、《電子病歷基本規范》(衛醫政發〔2010〕24號)、《衛生信息基本數據集編制規范》(WS 370-2012)、《衛生管理基本數據集》(WS374-2012)與《電子病歷基本架構與數據標準》(衛辦發〔2009〕130號)等。在數據值編碼標準方面,國際上有疾病分類編碼ICD-10、手術操作編碼ICD-9、SNOMED術語庫;國內有《衛生機構(組織)分類與代碼表》(WS2182002)、《社會保險藥品分類與代碼》(LD/T90-2012)和《中醫病證分類與代碼》(GB/T15657-1995)。
雖然國家已經規范了各種醫療元數據,然而在實際落地過程中,這些標準會根據應用進行不同程度的刪減和擴充,甚至出現錯誤的使用。因此,需要基于標準建立和實現元數據管理系統,實現對元數據的統一管理,與各個應用關聯,從而實現元數據的統一。
2、主數據管理
醫療數據的主數據主要有病人信息和醫生信息兩類。目前,在醫院層面,各業務系統對病人的信息分別進行存儲,但大型醫院都建立了臨床數據中心(CDR),為了唯一標識一個病人,需要通過構建病人主索引號(EMPI)將存儲于不同系統的病人關聯在一起。這里有兩個問題:
為此,需要在定義系統主數據的情況下,構建主數據管理中央庫,解決主數據碎片問題。可以從各業務系統抽取數據,并進行數據融合,形成完備的主數據信息,然后再將主數據信息分發給各業務系統,保證各業務系統中這些信息的準確性和完整性。這樣就形成了公共的重要屬性由主數據管理系統管理、各業務系統的特定屬性由各系統獨立管理的模式。
在構建主數據管理庫時,首先從多個異構的業務子系統中以ETL的方式抽取關鍵數據,然后利用元數據庫對其中的編碼、描述進行標準化。接著通過匹配算法完成對數據的錯誤消除和信息融合各個業務系統的差異性數據。對于匹配不到的孤立信息,監控跟蹤,以及人工處理。同時進匹配算法,最后將歸整好的主數據信息并入主數據庫。
3、數據質量管控子系統
從數據產生過程來看,醫療數據質量問題主要來源于3個方面。
在醫療數據治理過程中,需要了解最終的使用場景,也需要從業務系統的數據源頭控制質量,并保證每個融合和加工過程的正確性。另外出現數據錯誤時,進行數據修正。
因此質量管控平臺包括了數據質量監控、數據質量評估以及數據修正。數據質量監控主要針對從業務系統抽取的或是從外部傳送的接口數據,從及時性、有效性和完整性等幾個指標監測接口內容本身的數據質量問題,對采集程序進行監控;數據質量評估是指對融合后的數據進行質量評估。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。