ddd數據是怎麼存儲的

㈠ 什麼叫數據的邏輯結構 什麼叫數據的存儲結構

一、數據的邏輯結構。

系統的邏輯結構是從思想的角度上對系統分類，把系統分成若干個邏輯單元，不同邏輯單元分別實現自己的功能。數據的邏輯結構是對數據之間關系的描述，有時就把邏輯結構簡稱為數據結構，數據的邏輯結構分為以下四種：

1、集合結構：集合結構的集合中任何兩個數據元素之間都沒有邏輯關系，組織形式鬆散。

2、線性結構：數據結構中線性結構指的是數據元素之間存在著「一對一」的線性關系的數據結構。

3、樹狀結構：樹狀結構是一個或多個節點的有限集合。

4、網路結構：網路結構是指通信系統的整體設計，它為網路硬體、軟體、協議、存取控制和拓撲提供標准。

二、數據的存儲結構。

數據的存儲結構是指數據的邏輯結構在計算機中的表示。數據的存儲結構分為順序存儲結構和鏈接存儲結構兩種。

1、順序存儲結構：順序存儲方法它是把邏輯上相鄰的結點存儲在物理位置相鄰的存儲單元里，結點間的邏輯關系由存儲單元的鄰接關系來體現，由此得到的存儲表示稱為順序存儲結構。

2、鏈接存儲結構：鏈接存儲方法它不要求邏輯上相鄰的結點在物理位置上亦相鄰，結點間的邏輯關系是由附加的指針欄位表示的。由此得到的存儲表示稱為鏈式存儲結構，鏈式存儲結構通常藉助於程序設計語言中的指針類型來實現。

(1)ddd數據是怎麼存儲的擴展閱讀：

順序儲存結構的原理

在順序存儲中，每個存儲空間含有所存元素本身的信息，元素之間的邏輯關系是通過數組下標位置簡單計算出來的線性表的順序存儲，若一個元素存儲在對應數組中的下標位置為i，則它的前驅元素在對應數組中的下標位置為i－1，它的後繼元素在對應數組中的下標位置為i＋1。

㈡ java程序中數據的儲存方法有哪些

java程序中數據儲存方法如下：
一種是棧內存，另一種是堆內存
(1)在函數中定義的基本類型變數（即基本類型的局部變數）和對象的引用變數（即對象的變數名）都在函數的棧內存中分配；
(2)堆內存用來存放由new創建的對象和數組以及對象的實例變數（即全局變數）。
在函數（代碼塊）中定義一個變數時，java就在棧中為這個變數分配內存空間，當超過變數的作用域後，java會自動釋放掉為該變數所分配的內存空間；
在堆中分配的內存由java虛擬機的自動垃圾回收器來管理
堆和棧的優缺點
堆的優勢是可以動態分配內存大小，生存期也不必事先告訴編譯器，因為它是在運行時動態分配內存的。
缺點就是要在運行時動態分配內存，存取速度較慢；
棧的優勢是，存取速度比堆要快，僅次於直接位於CPU中的寄存器。

㈢ 浮點數的存儲結構是怎樣的

浮點數存儲時有符號位，階數位和尾數三部分組成。

解：最大的正數= (1-2 ^ (7))x 2 ^ (2 ^ (3) - 1) = (1-2 ^ (7)) x 2 ^(7) = 127，規則最小的正數＝2×2＾（－1）（或2＾（3））x＾2＝2－1＝2＾（8）（9）＝1／512。

最明顯的絕對值是－1＊2＾（2＾3－1）也就是－1＊2＾7，也就是－128。

(3)ddd數據是怎麼存儲的擴展閱讀：

浮點數A由兩個數字m和e表示：A＝m＊b＾e。在任何這樣的系統中，我們選擇基數b（計數系統的基礎）和精度p（要存儲的比特數）。

M（即尾數）的形狀陸雹為±d．dd…DDD的p位（每個位早塵帆是0和b－1之間的整數，包括0和b－1）。如果m的第一個數字是一個非零整數，那麼m就被歸一化了兄纖。

一些描述使用單個符號位（s表示＋或－）表示加號或減號，因此m必須是正數。E是a的指數。

結構：

表示計算機中的一個浮點數，其結構如下：

尾數部分（定點小數）指令碼部分（定點整數）

㈣ 浮點型數據在內存中實際的存放形式(儲存形式)

浮點型數據在內存中存儲不是按補碼形式，是按階碼的方式存儲，所以雖然int和float都是佔用了4個位元組，如果開始存的是int型數據，比如是個25，那麼用浮點的方式輸出就不是25.0，也許就變的面目全非。
你可以用共用體的方式驗證一下。在公用體中定義一個整形成員變數和一個浮點型成員變數，給整形賦值25，輸出浮點成員變數，你就知道了。

㈤ 科力達rtk手部5,點測量數據,怎麼保存

科力達rtk手部5，點測量數據保存方法為：
1、打開RTK手簿昌肢察開關打開工飢讓程之星。
2、找到工程並點擊進入文件導入導出，然後點擊文件導出。
3、進入導出界面，選擇導出類型，一般習慣使用南方CASS的，A會選擇dat類型，B經緯度默認，C選擇測量文件（所需的數據保存的文件）。
4、找到上一步的測量文件以後，點擊確定。
5、點擊成果文件，最好是新建一個文件，方便查詢，這兒我新建的ddd文件名作為演示。
6、測量文件和成果文件選擇好了以後，點擊導出。
7、此時，界面現實導出成功，並且現實你所保存耐茄的文件目標地址，你需要記住這個地址，方便電腦上查找。

㈥ DDD領域驅動設計-DDD概覽

# DDD概覽

## 啟迪

領域可以理解為業務，領域專家就是對業務很了解的人。

限界上下文也就是微服務的邊界，也可以理解為微服務，一個限界上下文=一個微服務。

個人理解領域驅動設計就是微服務驅動設計，從戰略上先進行微服務的劃分，從戰術上針對某個微服務進行領域模型的設計也就是業務模型的設計。

領域模型包括：
- 實體
- 值對象
- 聚合
- 領域服務
- 領域事件
- 資源庫
- 應用服務

## 什麼是領域驅動設計?

理解領域驅動設計是什麼之前，我們先來理解下什麼是領域？
領域可以理解為業務，領域專家就是對業務很了解的人。
領域驅動設計的核心就是和最了解業務的人也就是領域專家一起通過領域建模的方式去設計我們的軟體程序。

- 那麼領域如何驅動設計？或者說業務如何驅動設計？

傳統開發過程我們都是基於面向數據開發，拿到產品原型腦海里想著都是應該創建哪些表和哪些欄位才能滿足需求。
而領域驅動設計開發過程是讓拍譽螞我們基虛瞎於面向業務開發、面向領域模型開發。

領域模型的核心是通過承載和保存領域知識，並通過模型與代碼的映射將這些領域知識保存在程序代碼中，
在傳統開發中，當業務被轉換為一張張數據表時，丟失最多的就是領域知識(領域知識也就是我們在模型中定義的一些業務邏輯行為)。

面向領域模型開發的優點：
- 存儲方便，統一使用JSON進行存儲。
> 例：
> 訂單領域包含基礎信息、商品信息、金額信息、支付信息等包含訂單全生命周期的子域，
> 對於傳統面向數據的開發模式我們需要創建N張表進行存儲訂單的信息，但是面向領域開發時我們
> 可以通過利用nosql資料庫(mongo、es等)進行保存整個訂單域的信息，提高查詢、更新效率，簡化代碼
- 復用性高，引用某個領域模型，就可以擁有該領域模型的所有行為。
> 例：
> 基於微服務架構下，某個電商應用需要一個判斷某個訂單是否是在線支付訂單的邏輯時，
> 對於傳統的開發模式我們需要調用訂單中心的服務查詢訂單信息，然後寫一個判斷是否在線支付訂單的方法。
> 如果有多個應用都需要這個邏輯時，每個應該都需要重復寫相同的方法。
> 但面向領域開發時，只需要引用訂單中心的jar包，然後統一調用訂單領域內的方法即可。
> 這樣就實現了業務的高內聚

## DDD可以做什麼

DDD主要分為兩個部分，戰略設計與戰術設計

- 戰略設計
- 圍繞微服務拆分
- 戰術設計
- 微服務內部設計

## DDD怎麼做

- 戰略設計
- 和領域專家一起通過(過往經驗、事物聯系、事件風暴等)劃分【限界上下文】
> 限界上下文也就是微服務的邊界，也可以理解為微服務。
> 一個限界上下文=一個微服務
- 戰術設計
- 開發人員通過(領域模型)保存【領域知識】
> 領域知識也就是事物(角色)、行為(規則)和關系
>

## DDD領域模型

領域模型包含什麼？

- 實體
> 具有唯一標識，包含著業務知識的【充血模型】對象，用於對唯一性事物進行建模。
> 例襲埋：
> ```
> public class Order {
> private long orderId;
> private OrderAmount amount;
> private List item;
> }
> ```
- 值對象
> 生成後即不可變對象，通常作為實體的屬性，用於描述領域中的事物的某種特徵。
> 例：
> ```
> public class OrderItem {
> private long orderId;
> private String proctCode;
> private String proctName;
> }
> ```
- 聚合
> 將實體和值對象在一致性邊界之內組成聚合，使用聚合劃分微服務(限界上下文)內部的邊界
- 領域服務
> 分擔實體的功能，承接部分業務邏輯，做一些實體不變處理的業務流程。不是必須的
> 主要承接內部領域服務調用和外部微服務調用，及一些聚合業務邏輯處理。
> 例：
> ```
> @Service
> public class ShoppingcartDomainService {
> private final ShoppingcartRepository shoppingcartRepository;
> private final ProctFacade proctFacade;
> private final UserFacade userFacade;
> private final PromotionFacade promotionFacade;
>
>
> // 1.查詢購物車信息
> ShoppingcartDO entity = shoppingcartRepository.loadShoppingcart(userId);
>
> // 2.調用【用戶中心】服務查詢用戶信息
> User user = userFacade.getUser(userId);
>
> // 3.調用【商品中心】服務查詢商品信息
> Proct proct = proctFacade.getProct(proctCode);
>
> // 4.調用【活動中心】服務查詢活動信息
> Promotion promotion = promotionFacade.getPromotionByProctCode(proctCode);
>
> // 5.創建購物車實體
> Shoppingcart shoppingcart = new Shoppingcart(entity.getId, user, proct, promotion);
>
> // 6.購物車按活動分組
> shoppingcart.groupby4Promotion();
> }
> ```
>
>
- 領域事件
> 表示領域中發生的事情，通過領域事件可以實現本地微服務(限界上下文)內的信息同步，同時也可以實現對外部系統的解耦
- 資源庫
> 保存聚合的地方，將聚合實例存放在資源庫(Repository)中，之後再通過該資源庫來獲取相同的實例。
>
- 應用服務
> 應用服務負責流程編排，它將要實現的功能委託給一個或多個領域服務來實現，
> 本身只負責處理業務用例的執行順序以及結果的拼裝同時也可以在應用服務做些許可權驗證等工作。
> 

㈦ 領域驅動設計（DDD）實踐之路（第二篇)

在領域驅動裡面，infrastructure作為基礎設施，是提供技術細節的模塊。需要強調的是，很多人會誤以為infrastructure就是傳統的DAO層，其實infrastructure包括但氏明閉不限於DAO層，比如文件處理，三方調用，使用緩存，發送非同步消息等具體的技術細節實現都存在於infrastructure層。那麼技術細節是什麼呢。在我們看來，技術細節包含以下特徵

案例1：我們的實體需要持久化（存儲），所以我們需要提供存儲的實現。領域層的repository.save等方法提供了持久化介面約定，對於infrastructure來說，如何實現這個方法的代碼，就是技術細節。那麼我們如何實現這個過程呢？自然是選擇緩存，OSS存或者資料庫存。如果選擇資料庫，則進而需要選擇orm框架，配置...，實現repository.save的介面，這些都屬於持殲裂久化所需的技術細節代碼。

案例2：我們的槐扒應用需要導出資產包相關的excel形式數據，那麼當導出資產包數據時，文件領域模塊提供了導出的統一介面，資產領域模塊提供了資產包的適配介面，而導出excel的代碼需要使用easyExcel或者POI等第三方框架，屬於技術細節代碼。

案例3: 接案例2，為了實現導出時所需的excel排版格式，排版本身的格式與業務有關，比如在我們的業務場景下，我們導出調解明細（我們項目特定的一個領域模型）的時候，只需要按照常見的導出方式即可，而導出資產明細（我們項目特定的一個領域模型）則需要解析拼接所有的動態數據列，合並顯示每條數據不同的動態列，而這一切是由業務決定的。根據業務不同有不同的排版要求這一點體現了資產域需要提供文件域的導出策略，調解域也需要實現文件域的導出策略。這些都屬於描述業務信息的約定，而這些約定的具體實現比如怎麼把實體的那一個屬性映射到excel的哪一行哪一列，則屬於技術細節。這種區分方式顯性化了業務的概念，同時又將實現放在了基礎設施層，提供了一定的解耦性。

說完了infrastructure的技術細節的定義，我們接下來聊幾個在採用DDD研發模式下，infrastructure層開發過程中經常會遇到的一些問題及我們的解決方案。

為了讓業務邏輯和代碼實現解耦，在repository的約定中，我們通常用「save保存」代替我們通常說的「insert（插入）「，」update（更新）」這樣的技術術語，以屏蔽技術細節。這樣帶來的一個副作用是，在save時就需要根據策略判斷調用insert還是update，我們使用的策略是根據id是否是空決定，即我們所有的實體對象都有一個屬性，類型為Id類的子類，id對象的屬性（資料庫裡面實際存放的id值）可能為null，但是id對象，本身不會為null，根據這個對象可以判斷當前實體id是否為空。

對於聚合場景，子實體是需要知道聚合根的id的，因為在存儲到資料庫時可能需要以外鍵的方式存儲對象間的映射關系。

然而，在具體實現中，我們認為，實體之間的對象關系才是標識兩個實體之間關系的方式，而不是id，所以生成實體時，先通過對象引用關聯對象，表明聚合和實體之間的關系，在保存到資料庫的時候，通過實體生成資料庫映射類的時候就可以知道當前數據的id是否為空，同時又能知道當前數據之間的關系。

對象之間的關系在1:1聚合保存的時候可能體現不明顯，但是當1:N或者N:N批量保存聚合的時候，作用就比較明顯了。在我們的系統中發起調解業務就需要批量保存調解批次。代碼如下（歡迎吐槽，擁抱進步）

通過這種方式就解決了批量插入不能返回id，同時又能繼續復用id.isNew()判斷是否為新數據的方式（這里我們沒有創建entity基類，所以判斷放在了Id上）。

以上方法提供了批量保存時如何區分是新增還是更新。下面我們來談談我們項目內提供的插入和更新模板代碼。

對於領域來說，save是基本的保存代碼。方法傳入的參數往往是一個存在於內存中的聚合根對象，有時包含全量的子實體，VO和全量的欄位，而在插入場景，對批量請求我們希望支持批量插入，減少對資料庫的IO頻率，在更新場景下，我們希望減少update時的更新欄位的數量（只更新需要更新的欄位），這有助於減少資料庫IO次數、binlog大小和mysql資料庫索引變更帶來的開銷，所以是非常有必要的。因此對於infrastructure來說，可以提供統一的定製化模板方便repository定製化更新欄位的方法快速實現。

由於我們的系統使用的是mybatisplus的ORM方案，所以我們根據api和mysql的批量語句開關提供了一個批量插入和批量更新的Mapper基類，其中insertBatchSomColumn是mybatisplus自帶的，updateBatchById則是我們實現的，文檔鏈接如下https://mp.toutiao.com/profile_v4/graphic/preview?pgc_id=7062223527654916621通過這種方式可以輕松地提供定製化更新某幾列的sql，減輕sql編寫負擔。

這一次要講的其實就是上面提到過的excel導入導出的案例。對於我們的系統來說，具有資產域，文件域，調解域等。其中資產域、調節域等三個域需要導入導出excel。但是我們在設計的時候認為文件的操作屬於文件域的概念，所以應當由文件的domain提供功能。但是很明顯，具體的導入導出的策略根據數據的不同是可以變化的。所以針對這種情況，我們回歸到領域驅動的實現的本質------面向對象技術來思考這個問題的優雅解法。以導入為例

代碼如下

上面4份代碼是domain的，最下面的是infrastructure的，這里我們只講infrastructure的（但是我個人認為領域分層後還是需要整體考慮的，所以才會貼上domain的代碼）。

這是我們對於跨域業務邏輯的處理辦法。

為了保證各領域模型間的解耦，我們經常通過最輕量級的領域事件的方式實現，而不是類似metaq，msgbroker這樣的非同步分布式消息中間件。領域事件的發送有很多的實現方案，我們傾向於直接使用spring的功能，因為我們需要同步保證事務。但是spring的event發送需要繼承ApplicationEvent而領域事件我們又希望獨立於spring的event體系，所以我們通過對spring的了解發現了spring已經提供了 PayloadApplicationEvent 可以實現這種功能實現上和其他的spring的event一致，獲取我們自己定義的event的方法如下

這里的getPayload()可以獲取到我們放進去的領域事件TimeoutEvent

在任何系統中都會有批處理的業務。可能是批處理聚合，可能是批處理聚合內的實體類。這里說一下我之前遇到的一個帖子（jdon）上的討論。帖子上說的是有一個排班業務，一條班表數據作為聚合存在著每日排班子實體，每日排班下又存在著排班明細子實體，當日期逐漸增加時一條排班需要載入好幾年的數據用於生成聚合，而實際上則僅僅只需要計算最近幾周的數據。這里存在兩點問題

第一點自然不用多說，技術實現以提供業務功能為核心是我一直以來的主張。所以當數據量可能會不斷增大的情況下不用載入完整自然是必須的（哪怕內存存儲的下也應當盡可能少的消耗）。第二點來說帖子的一位回復者傾向於DomainService提供專門的適配方法，用於載入幾周的數據。

我們的系統中存在一個有一些類似的業務。我們的系統需要每隔幾分鍾就運行一次批處理任務，獲取所有已經過期的調解明細，並且設置為過期。調解明細屬於調解批次的聚合，所以我們有同樣的需求。

我們在此提供一種我們的實現，供參考。

repository的實現根據面向對象原則，僅僅提供如何查詢過濾資料庫數據

迭代器的實現提供了迭代職責實現

至此實現了批處理載入聚合的邏輯，同時可以提供聚合的部分載入（需要注意業務的正確性不會因為聚合的不完全載入而產生問題）。

最後總結一下