領(lǐng)域邏輯

表模塊和數(shù)據(jù)集一起工作->
先查詢(xún)出一個(gè)記錄集，再根據(jù)數(shù)據(jù)集生成一個(gè)（如合同）對(duì)象，然后調(diào)用合同對(duì)象的方法。
這看起來(lái)很想service查詢(xún)出一個(gè)對(duì)象，但調(diào)用的是對(duì)象的方法，這看起來(lái)像是充血模型，如果getter和setter也算，那貧血模型才算，不然我們是調(diào)用service的方法。當(dāng)然，service是把充血模型拆出來(lái)了。說(shuō)到底這個(gè)時(shí)候查詢(xún)的方法反而不像是在整個(gè)領(lǐng)域模型中了
那如果我們靈活些，把出了查詢(xún)的mapper以外的部分當(dāng)作，額，，是不是就是表模塊這種組織形式了呢？
表模塊是事務(wù)腳本和領(lǐng)域模型的一個(gè)中間地帶。它圍繞表而非直接圍繞過(guò)程來(lái)組織領(lǐng)域邏輯，提供了更多的結(jié)構(gòu)，而且更容易發(fā)現(xiàn)和移除冗余代碼。
同領(lǐng)域模型相比，你無(wú)法應(yīng)用許多在領(lǐng)域模型中可以使用的組織細(xì)粒度邏輯結(jié)構(gòu)的技術(shù)，例如繼承承、策略和其他面向?qū)ο蟮脑O(shè)計(jì)模式。
面向?qū)ο蟮暮锰幨菍⒊绦蚪Y(jié)構(gòu)化嗎
表模塊最大的優(yōu)勢(shì)在于與雙層架構(gòu)的已有代碼的銜接。
雙層架構(gòu)、GUI程序通常設(shè)計(jì)成與sql返回的記錄集工作，而表模塊也再記錄集之上工作。
加了記錄集就成三層了。相當(dāng)于重構(gòu)了
許多平臺(tái)都使用這種開(kāi)發(fā)網(wǎng)格，尤其是微軟的COM和.NET

書(shū)中并沒(méi)有討論什么是領(lǐng)域邏輯的復(fù)雜度，，為什么銀行業(yè)務(wù)甚至直接用存儲(chǔ)過(guò)程就可以？那種是不復(fù)雜的業(yè)務(wù)邏輯嗎？企業(yè)應(yīng)用經(jīng)常修改算是復(fù)雜的業(yè)務(wù)邏輯嗎？一個(gè)事件牽扯一堆事件，且經(jīng)常修改算是嗎？

數(shù)據(jù)源層

數(shù)據(jù)源層的作用是與應(yīng)用需要的基礎(chǔ)設(shè)施的不同部分進(jìn)行通信。
對(duì)web開(kāi)發(fā)者而言，在數(shù)據(jù)層可以編寫(xiě)和數(shù)據(jù)庫(kù)通信的相關(guān)代碼已經(jīng)是很常見(jiàn)的應(yīng)用場(chǎng)景了。但這里應(yīng)當(dāng)注意到，數(shù)據(jù)源可以是任何數(shù)據(jù)來(lái)源，比如其他系統(tǒng)（如調(diào)用微服務(wù)接口）
關(guān)系數(shù)據(jù)庫(kù)之所以取得成功，最重要的原因之一就是SQL的存在，它是數(shù)據(jù)庫(kù)通信標(biāo)準(zhǔn)語(yǔ)言。

從3.1的第二段（解釋為什么將sql放在單獨(dú)的類(lèi)中）來(lái)看，似乎當(dāng)時(shí)后端程序猿和DBA并沒(méi)有混為一談，程序員不一定擅長(zhǎng)sql，DBA則不接觸代碼（文中提到他們希望能得到訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的sql，我猜測(cè)他們只是負(fù)責(zé)管理數(shù)據(jù)庫(kù)、建立庫(kù)表之類(lèi)的？）
不管怎么說(shuō)，對(duì)于現(xiàn)在的開(kāi)發(fā)者而言，單獨(dú)一層管理sql也是個(gè)方便的選擇。

行數(shù)據(jù)入口

查詢(xún)語(yǔ)句的每一行產(chǎn)生一個(gè)實(shí)例。用面向?qū)ο蟮姆绞娇创龜?shù)據(jù)
查詢(xún)出的一行不一定是一個(gè)表的吧？也不一定是一個(gè)領(lǐng)域

表數(shù)據(jù)入口 返回記錄集

對(duì)數(shù)據(jù)庫(kù)中的每個(gè)表，僅僅需要一個(gè)對(duì)象來(lái)管理。
記錄集是一種通用數(shù)據(jù)結(jié)構(gòu)？
GUI工具通常使用記錄集

表數(shù)據(jù)入口與記錄集非常匹配，這使得它們成為使用表模塊的當(dāng)然選擇。它也是一個(gè)組織存儲(chǔ)過(guò)程的模式。

活動(dòng)記錄?

• 在一片博客中，稱(chēng)Active Record and Data Mapper 是ORM的兩種流行的實(shí)現(xiàn)。

領(lǐng)域和數(shù)據(jù)庫(kù)表一一對(duì)應(yīng)?這幾把講的都是啥，下面的數(shù)據(jù)映射器？
從另一個(gè)角度來(lái)考慮活動(dòng)記錄，就是從行數(shù)據(jù)入口開(kāi)始，然后把領(lǐng)域邏輯加入到類(lèi)中，特別是在從多個(gè)事務(wù)腳本中發(fā)現(xiàn)了重復(fù)代碼的時(shí)候。

數(shù)據(jù)映射器

一種更好的辦法是把領(lǐng)域模型和數(shù)據(jù)庫(kù)完金獨(dú)立，可以讓間接層完成領(lǐng)域?qū)ο蠛蛿?shù)據(jù)庫(kù)表之間的映射。這個(gè)數(shù)據(jù)映射器(見(jiàn)圖3-4)處理數(shù)據(jù)庫(kù)和領(lǐng)域模型之間所有的存取操作，并且允許雙方都能獨(dú)立變化。這是數(shù)據(jù)庫(kù)映射架構(gòu)中最復(fù)雜的架構(gòu)，但它的好處是把兩個(gè)層完全獨(dú)立了。

遇事不決加一層是吧.還最復(fù)雜的架構(gòu),您前面那也配叫數(shù)據(jù)庫(kù)映射架構(gòu)?好吧好吧,就當(dāng)他們是吧
獨(dú)立變化?哦哦哦我明白了,內(nèi)存改完不同步數(shù)據(jù)庫(kù),直到調(diào)用方法?看來(lái)前面的并沒(méi)有g(shù)etter setter這種情況了,前面的都是做某種操作的時(shí)候直接update之類(lèi)來(lái)代替getter/setter?

簡(jiǎn)單的邏輯用活動(dòng)記錄也行,復(fù)雜的用數(shù)據(jù)映射器.其實(shí)就是加了一層
即使用數(shù)據(jù)映射器作為首選持久化機(jī)制，還是可以使用數(shù)據(jù)入口來(lái)封裝被視為外部接口的表或者服務(wù)。

說(shuō)到最后主要還是領(lǐng)域模型難以持久化?？雌饋?lái)領(lǐng)域和實(shí)體實(shí)際上不是什么很匹配的概念?？赡鼙緛?lái)就是一個(gè)強(qiáng)調(diào)解耦，一個(gè)強(qiáng)調(diào)關(guān)系吧
作者推崇面向?qū)ο髷?shù)據(jù)庫(kù)。然后是數(shù)據(jù)映射器。我不太理解都買(mǎi)的商業(yè)OR工具有什么
還有一種面向?qū)ο髷?shù)據(jù)庫(kù)風(fēng)格的邏輯層，如JDO

行為問(wèn)題

工作單元：又加了一層控制何時(shí)加載對(duì)象
領(lǐng)域模型關(guān)聯(lián)對(duì)象：延遲加載避免一次加載一批

3.3 讀取數(shù)據(jù)

查找器方法
設(shè)計(jì)經(jīng)驗(yàn)：
讀取冗余行也可以，一次讀很多行效率大于讀很少的幾行
join一次讀取多個(gè)表可能比多次讀取表更快？當(dāng)然MF也說(shuō)了一次查詢(xún)最多三到四次join
讀到這一段，下面說(shuō) 設(shè)計(jì)一個(gè)入口獲得相聯(lián)結(jié)的表數(shù)據(jù)，或者通過(guò)一個(gè)數(shù)據(jù)映射器用一次調(diào)用加載多個(gè)領(lǐng)域?qū)ο蟆?/em>，可能數(shù)據(jù)映射器，，額，，還有上面的工作單元中間層，，是指，內(nèi)存中對(duì)象保存的數(shù)據(jù)類(lèi)似于緩存層？直接操作對(duì)象來(lái)改變其對(duì)應(yīng)的數(shù)據(jù)庫(kù)數(shù)據(jù)？這樣一來(lái)，set方法可能其實(shí)就類(lèi)似update，但是直接set到數(shù)據(jù)庫(kù)里；工作單元相當(dāng)于緩存策略里面的有中間manager管理的；
畢竟這個(gè)時(shí)候MF提出的領(lǐng)域模型的概念似乎還沒(méi)有和javabean融合，沒(méi)有g(shù)etter一說(shuō)。

3.4 結(jié)構(gòu)映射模式

對(duì)象-關(guān)系映射的結(jié)構(gòu)映射模式
表數(shù)據(jù)入口通常不需要；
行數(shù)據(jù)入口和活動(dòng)記錄可能會(huì)需要一些模式；
數(shù)據(jù)映射器需要全部模式。

對(duì)象和表處理“連接”關(guān)系的方法是相反的
這是范疇論的連接嗎
一對(duì)多關(guān)系為例，對(duì)象可以保存多個(gè)其他對(duì)象的引用列表，數(shù)據(jù)庫(kù)則是由多的一方保存1的一方的主鍵。

新出現(xiàn)的名詞：外鍵映射，標(biāo)識(shí)映射，依賴(lài)映射。
可能是指關(guān)系型數(shù)據(jù)庫(kù)吧。因?yàn)橄旅嬗痔岬搅硕鄬?duì)多關(guān)系用的關(guān)聯(lián)表映射。
還是沒(méi)搞懂標(biāo)識(shí)域是什么？一個(gè)成員變量，保存外鍵，而不是用引用？

繼承

單表繼承
具體表繼承
類(lèi)表繼承

單表繼承：一個(gè)層次中的所有類(lèi)建立一個(gè)表。
說(shuō)的這么玄乎，結(jié)果就是一個(gè)大表把所有父類(lèi)和子類(lèi)的屬性都放上啊?！皩哟巍敝傅氖菑母割?lèi)和它的子類(lèi)啊，咱對(duì)層次的理解是不是有些偏頗？

類(lèi)表繼承是類(lèi)和表之間最簡(jiǎn)單的關(guān)系，但是它需要多個(gè)連接(join)操作來(lái)載人一個(gè)對(duì)象，這樣通常損失了性能。
具體表繼承避免了連接操作，允許從一個(gè)表中取得一個(gè)對(duì)象，但是改變起來(lái)比較困難。對(duì)超類(lèi)的任何改變都不得不改變所有的表(還有映射代碼)。改變層次結(jié)構(gòu)自身會(huì)帶來(lái)更大的改變。缺乏超類(lèi)表也能使主鍵管理十分可怕，引用完整性也有問(wèn)題，盡管它能減少超類(lèi)表中的鎖爭(zhēng)奪。
而在某些數(shù)據(jù)庫(kù)中，單表繼承最大的弊端是浪費(fèi)了空間，因?yàn)槊恳恍卸急仨殲槊糠N可能的子類(lèi)保留一些列，這就導(dǎo)致很多空列。然而，許多數(shù)據(jù)庫(kù)都能很好地壓縮浪費(fèi)的表空間。單表繼承的另一個(gè)問(wèn)題在于它的大小將成為訪(fǎng)問(wèn)的瓶頸。它最大的好處是把所有的內(nèi)容都放到一起，這樣修改起來(lái)很容易并目避免了連接操作。
我們可以混合操作，比如一些字段放在大表里，一些作為附加字段。但這樣設(shè)計(jì)十分復(fù)雜。
我們的實(shí)踐中還有一種方法是放數(shù)據(jù)庫(kù)的一列json中

映射到數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)方案是什么?是指“是否已經(jīng)建立好了表”嗎？

也許應(yīng)該關(guān)注下ORM思想的誕生，這一層次
這本書(shū)還有個(gè)缺點(diǎn)，參考書(shū)目在電子版全都沒(méi)有顯示出來(lái)，，

web表現(xiàn)層

輸入控制器：MVC中的控制器
看來(lái)model下面還有數(shù)據(jù)源層
兩種模式：

• 頁(yè)面控制器，為每個(gè)頁(yè)面準(zhǔn)備一個(gè)控制器
• 為每一種動(dòng)作準(zhǔn)備一個(gè)控制器

分布策略

本地的過(guò)程調(diào)用非?？?br /> 本地接口細(xì)粒度，方便拓展（有些像貧血模型）
遠(yuǎn)程接口粗粒度，一次做很多事情，減少調(diào)用次數(shù)

分布模型：CORBA

因此MF認(rèn)為不要分布使用對(duì)象，而是用集群系統(tǒng)，在一個(gè)cpu部署所有對(duì)象并在其他節(jié)點(diǎn)部署他們