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