人們可以使用許多方法來處理影象和影片，因此谷歌透過釋出更易於發現篡改的線上內容的工具來為最糟糕的情況做準備。隨著2020年美國總統大選的臨近，科技巨頭們正在尋找不同的方式來對抗假新聞，錯誤資訊以及在大型社交和搜尋平臺上傳播deepfakes影片的情況。

這些工具是免費的，並且雖然公認是“早期實驗平臺”的一部分，但它們是一個很好的起點，其中包括來自加州大學伯克利分校，那不勒斯菲裡德里克第二大學和馬里蘭大學的學者的貢獻。

彙編程式的工作方式是將幾種機器學習演算法組合在一起，這些演算法擅長查詢顏色和噪聲圖案，噪聲圖案中的不一致之處以及檢視各種影象中畫素的屬性。

Assembler擅長檢測影象中最常用的篡改技術，例如播放亮度或複製和貼上紋理或物件以掩蓋某物或某人。它帶有一個分數，該分數代表圖片可能被篡改或以任何其他方式更改的可能性，類似於Adobe的About Face AI。該專案的另一個目標是微調可以發現使用StyleGAN建立的 deepfakes，StyleGAN是一種能夠產生令人信服的假想面孔的演算法。

Jigsaw執行長Jared Cohen在部落格文章中解釋說，該公司“觀察到虛假資訊以被用於操縱選舉，發動戰爭和破壞公民社會的方式的發展。” 這種認識導致決定開發用於阻止這些嘗試的技術。

在撰寫本文時，Assembler具有七個不同的工具，記者和其他人可以使用它們來發現遭篡改的影象。但是，Jigsaw研究者Santiago Andrigo和Andrew Gully告訴《紐約時報》，彙編程式不是靈丹妙藥，作為一個生態系統，彙編程式需要隨著時間的推移快速發展和改進。

這就是Jigsaw還發布了一個名為“ The Current”的網路出版物的原因，該出版物將持續不斷地展示正在進行的有關檢測錯誤資訊活動的研究。Cohen表示：“我們的主要動機是建立一個場所，使人們可以訪問許多在處理此問題的第一線的專家，獨立研究人員和組織的工作。”

其彙編程式結合了學術界現有的幾種技術來檢測常見的操縱技術，包括更改影象亮度和將複製的畫素貼上到其他地方以掩蓋某些東西，同時保留相同的視覺紋理。它還包括一個檢測器，該檢測器可以發現使用StyleGAN建立的深層偽造品，StyleGAN是一種可以生成逼真的假想面孔的演算法。這些檢測技術會輸入到主模型中，該模型會告訴使用者影象被操縱的可能性有多大。

彙編程式是與受控媒體作鬥爭的重要一步，但它並未涵蓋許多其他現有的操縱技術，包括用於影片的操縱技術，隨著生態系統的不斷髮展，團隊需要對其進行補充和更新。它仍然作為與通常分發篡改影象的渠道分開的平臺而存在。專家建議，像Facebook和Google這樣的技術巨頭將這些型別的檢測功能直接整合到其平臺中。這樣，可以在上傳和共享照片和影片時幾乎實時地執行此類檢查。

也有其他方法可以考慮。例如，一些初創公司正在採用驗證技術，該技術可以在拍攝照片時記住照片中畫素的位置，但這也帶來了挑戰。最終，技術修復還遠遠不夠。數字偽造最棘手的方面之一併不是偽造影象本身。而是它們存在的想法，可以很容易地呼叫它們來質疑真實媒體的準確性。這是挑戰的型別，也將需要社會和政策解決方案。

據外媒Techspot報道，人們可以使用許多方法來處理影象和影片，因此谷歌透過釋出更易於發現篡改的線上內容的工具來為最糟糕的情況做準備。隨著2020年美國總統大選的臨近，科技巨頭們正在尋找不同的方式來對抗假新聞，錯誤資訊以及在大型社交和搜尋平臺上傳播deepfakes影片的情況。

這些工具是免費的，並且雖然公認是“早期實驗平臺”的一部分，但它們是一個很好的起點，其中包括來自加州大學伯克利分校，那不勒斯菲裡德里克第二大學和馬里蘭大學的學者的貢獻。

彙編程式的工作方式是將幾種機器學習演算法組合在一起，這些演算法擅長查詢顏色和噪聲圖案，噪聲圖案中的不一致之處以及檢視各種影象

Assembler擅長檢測影象中最常用的篡改技術，例如播放亮度或複製和貼上紋理或物件以掩蓋某物或某人。它帶有一個分數，該分數代表圖片可能被篡改或以任何其他方式更改的可能性，類似於Adobe的About Face AI。該專案的另一個目標是微調可以發現使用StyleGAN建立的 deepfakes，StyleGAN是一種能夠產生令人信服的假想面孔的演算法。

Jigsaw執行長Jared Cohen在部落格文章中解釋說，該公司“觀察到虛假資訊以被用於操縱選舉，發動戰爭和破壞公民社會的方式的發展。” 這種認識導致決定開發用於阻止這些嘗試的技術。

在撰寫本文時，Assembler具有七個不同的工具，記者和其他人可以使用它們來發現遭篡改的影象。但是，Jigsaw研究者Santiago Andrigo和Andrew Gully告訴《紐約時報》，彙編程式不是靈丹妙藥，作為一個生態系統，彙編程式需要隨著時間的推移快速發展和改進。

這就是Jigsaw還發布了一個名為“ The Current”的網路出版物的原因，該出版物將持續不斷地展示正在進行的有關檢測錯誤資訊活動的研究。Cohen表示：“我們的主要動機是建立一個場所，使人們可以訪問許多在處理此問題的第一線的專家，獨立研究人員和組織的工作。”

DDD 領域驅動模型設計中的分層架構

1. 為什麼要分層

軟體設計中分層的設計隨處可見，但是分層能帶來什麼好處呢？或者說，我們為什麼要考慮分層架構呢？

由於現實世界的複雜性，分層可以提供一個相對高層的視角來分解和簡化我們的問題，此外分層也可帶來可測試、可維護性、靈活性、可擴充套件性等方面的好處。

簡化複雜性，關注點分離，結構清晰；降低耦合度，隔離層次，降低依賴（上層無需關注下層具體實現），利於分工、測試和維護（可維護性）；提高靈活性，可以靈活替換某層的實現；提高擴充套件性，方便實現分散式部署；

看起來十分簡單，好像就是把系統劃分為一定的層數，並把他們堆疊組織起來。但是，當落實到具體的實踐時，如何劃分、各層存在的意義、如何取捨以及相應的依賴關係卻並沒有想象中那麼容易，邊界的重合部分、不同場景下關注點、層次內部的具體分解以及層次的粒度等都是我們需要考慮的問題。

2. 什麼是分層架構

2.1 分層的歷史

最廣為人知的應該就是經典的三層架構：展示層、業務邏輯層、資料訪問層。

Martin Fowler在《企業應用架構模式》中也是類似的三層進行展開的：表現層，領域層，資料來源層。

還有各種其他分層架構，這裡就不一一描述了。

面對如此多的分層架構，我們不禁思考，他們分層的依據又是什麼？能否抽象出一些相同點和不同點？又該在什麼時候加入哪些合適的中間層？在實踐中我們又該採取怎樣的架構呢?

2.2 分層的本質

分層其實是把一系列相同或相似的物件進行分類放在同一層，然後根據他們之間的依賴關係再確定上下層次關係。可以看出，分層的核心在於分類和關聯。

通常，我們可以將系統劃分為變化較大的業務部分和相對穩定的技術部分；對於業務來說，又可劃分為展示部分（前臺）和內部處理邏輯（後臺）兩大部分；展示又可分為資料/頁面部分和介面部分。如此不斷的進行細分和抽象，我們可以迭代出更細粒度的分類/層次，如下所示：

業務：需要重點關注，我們的目的也是分離出具體的業務領域邏輯：

外部展示（表現層/介面層）：資料、頁面（web）、遠端介面（interface/api）內部邏輯處理：應用邏輯（應用層/服務層）、具體業務邏輯（領域層）

技術：相對穩定，具體業務無關（基礎設施層）

資料訪問（資料訪問層）日誌、安全、異常、快取等

當然，分類並不唯一，基於不同的視角我們可能會有不同的分類標準。比如資料訪問層也可以歸類到業務相關/內部邏輯處理的部分，因為可能涉及到一些對具體業務表的操作。

此外，根據問題領域和解決方案的複雜程度，我們可以有不同的層次。比如在業務不太複雜時，我們可以把應用層和領域層合併為一層。

3. DDD經典分層架構

上面我們在分析分層的本質時也提到了一些基本的層次和分類標準，但那只是一個非常粗粒度的劃分。

在實際決策時，我們需要知道各層的職責、意義以及相應的場景；而落實到程式碼層面時，我們還需要知道各層所包含的具體內容、各層的一些常見的具體策略/模式、層次之間的互動/依賴關係。

首先我們來看一下Evans在《領域驅動設計》中提到的分層架構。

image

問：為什麼要分成這樣的四層？

分層主要目的是為了簡化複雜性，系統中最複雜的部分應該就是我們的業務邏輯。當系統互動或者工作流比較複雜時，我們會考慮從業務邏輯中抽出這部分作為應用層。而各個領域內的程式碼則化為領域層，這樣層級結構更加清晰。

3.1 使用者介面層/表示層

使用者介面層負責向用戶顯示資訊和解釋使用者指令。這裡指的使用者可以是另一個計算機系統，不一定是使用使用者介面的人。

該層包含與其他應用系統（如web服務、RMI介面或web應用程式以及批處理前端）互動的介面與通訊設施。

它負責輸入引數的解釋、驗證以及轉換。另外，它也負責輸出引數的序列化，如透過HTTP協議向web瀏覽器或web服務客戶端傳輸HTML或XML，或遠端Java客戶端的DTO類和遠端外觀介面的序列化。

可以看出，該層的主要職責是與外部使用者（包括web服務、其他系統）互動，如接受使用者的反饋，展示必要的資料資訊。主要包含web部分和遠端服務部分等。

web部分一般包含常見的Servlet，Controller等元件，而遠端介面部分主要由Facade、DTO和Assembler等構成。

Facade：遠端外觀，一個粗粒度的外觀，不含任何領域邏輯DTO：資料傳輸物件Assembler：物件組裝器，負責資料傳輸物件與領域物件相互轉換，不對外暴露

問：引數的校驗為什麼在使用者介面層？領域層的校驗和使用者介面層的校驗有什麼不同?

校驗應該取決於校驗的內容，一般推薦儘早校驗，不過這裡主要是進行一些簡單的、不涉及業務規則的校驗。具體的業務規則的校驗放在領域層。

問：為什麼需要DTO？DTO和VO是同一個東西嗎？

領域物件關係比較複雜，很難序列化，而且使用者很多時候並不需要整個模型，大部分時候需要的只是其中的一部分內容，DTO可以有效減少網路呼叫的開銷。此外，領域模型內部的邏輯也無需暴露給外部。

DTO一般用於遠端服務，如果是內部使用的話，一般可以直接使用領域物件。

VO中有前端狀態資訊，比如成功失敗等。

問：為什麼需要Assembler？

主要目的是解耦，負責資料傳輸物件和領域物件之間的相互轉換。BeanUtils也可以做到相應的功能（dozer相對好一些），不過Assembler更為清晰，安全與可控，缺點在於手工程式碼量稍多。

3.2 應用層

應用層定義了軟體要完成的任務，並且指揮表達領域概念的物件來解決問題。該層所負責的工作對業務來說意義重大，也是與其他系統的應用層進行互動的必要通道。

應用層要儘量簡單。它不包含任務業務規則或知識，只是為了下一層的領域物件協助任務、委託工作。它沒有反映業務情況的狀態，但它可以具有反映使用者或程式的某個任務的進展狀態。

應用層主要負責組織整個應用的流程，是面向用例設計的。該層非常適合處理事務，日誌和安全等。相對於領域層，應用層應該是很薄的一層。它只是協調領域層物件執行實際的工作。

綜上所述，應用層是表達user case和user story的主要手段，主要用於協調領域模型與其他應用元件的工作（並不處理業務邏輯）。

應用層中主要元件是Service，因為主要職責是協調各元件工作，所以通常會與多個元件互動，如其他Service，領域物件，Repostitory等。

一種比較常見的做法是：應用層通常接受來自使用者介面層的引數，再透過Repostitory獲取到聚合示例，然後執行相應的命令操作（很薄的一層）。

問：為什麼要有應用層？

業務比較複雜時，我們會從業務邏輯中拆分出應用層和領域層。

如果在領域物件中事先針對具體應用的邏輯，會降低應用之間的可重用性。

此外，如果將來需要加工作流之類的工具來實現應用邏輯，如果之前是混雜在一起的話則不好拆分。

3.3 領域層/模型層

領域層主要負責表達業務概念，業務狀態資訊和業務規則。

Domain層是整個系統的核心層，幾乎全部的業務邏輯會在該層實現。

領域模型層主要包含以下的內容：

實體(Entities):具有唯一標識的物件值物件(Value Objects): 無需唯一標識領域服務(Domain Services): 一些行為無法歸類到實體物件或值物件上，本質是一些操作，而非事物聚合/聚合根(Aggregates & Aggregate Roots): 聚合是指一組具有內聚關係的相關物件的集合，每個聚合都有一個和工廠(Factories): 建立複雜物件，隱藏建立細節倉儲(Repository): 提供查詢和持久化物件的方法

關於各個元素的具體含義、職責以及相關誤區，可參考領域建模核心概念解析.對於這些具體的物件，可定義一些標準領的來規範。

3.4 基礎設施層

基礎設施層為上面各層提供通用的技術能力：為應用層傳遞訊息，為領域層提供持久化機制，為使用者介面層繪製螢幕元件。

基礎設施層以不同的方式支援所有三個層，促進層之間的通訊。基礎設施包括獨立於我們的應用程式存在的一切：外部庫，資料庫引擎，應用程式伺服器，訊息後端等。

作為基礎設施層，為、和三層提供支撐。所有與具體平臺、框架相關的實現會在中提供，避免三層特別是層摻雜進這些實現，從而“汙染”領域模型。中最常見的一類設施是物件持久化的具體實現。

問: 作用是什麼？和的關係之前對也曾有過誤解（在我們的系統中有一個層位於和之間）。主要是從資料庫表的角度來看待問題的，並且提供操作（只是對資料庫表的一個封裝），是一種面向資料處理的風格（事務指令碼）；而(資源庫)和(資料對映器)更加面向物件，通常用於領域模型中。因為資料訪問層的暴露可能會破壞物件的封裝性，物件的關係和資料一致性也難以維護，所以 應該儘量避免在領域模型中使用模式，推薦使用聚合本身來管理業務邏輯。

4. 模型的形態

不同的架構、不同的層、不同的應用場景中有著不一樣的建模需求，因此表達相同概念的模型可能會有不同的形態，例如：

充血模型：領域模型架構中包含了領域邏輯和領域屬性的領域模型。失血模型：傳統三層架構中只有get/set方法，沒有業務邏輯的POJO物件。貧血模型：類似充血模型，但是不包括持久化相關邏輯。PO（Persistant Object）：持久化物件，即DAO從JDBC取出來的物件。傳統三層架構中，PO即POJO元件中的物件，存在於DAO和Service之間。DO（Domain Object）：領域物件，領域模型架構中，PO從資料庫取出來後，有一個“重建”的概念，即根據資料還原實體，這個被還原的實體就是DO，存在於DAO和Service之間。DTO（Data Transfer Object）：資料傳輸物件。對傳統三層架構來說，該物件存在於Service和Controller之間。PO到DTO的轉換可以在Service或Controller中實現。VO（View Object）：檢視物件。Controller在返回DTO給檢視時，可能還需要包括狀態資訊例如操作成功/失敗的狀態碼、提示文字等。這時就需要在DTO外面再包一層，即View Object。該物件存在於Controller和Web之間，由Controller進行裝配。