Cookie Cutter架構 - Janos Pasztor

架構
透過我的實驗，我提出了一個我想出的架構。重點不在於編寫最少量的程式碼。這也不是最快的寫入程式碼。重點是可預測性。換句話說，我討厭意外。當需求發生微小變化時，它不應該波及整個應用程式，搞亂一切。應該在一個地方捕獲第三方API更改或錯誤，並且不應導致級聯故障。
為了實現這一點，我的應用程式分為三層：API，業務邏輯和後端/儲存。這些層中的每一層僅負責一件事，並且它們在它們之間傳遞實體。（基本上，半啞semi-dumb資料傳輸物件DTO，banq注：如果作者懂DDD，用領域模型替代DTO就跟棒了！）。

API
該API負責處理與輸出介質。例如，如果API需要返回部落格帖子，但又想獲取所述部落格帖子的作者，則需要呼叫相應的業務邏輯類來執行該操作。例如：

class BlogPostGetApi {
  private final BlogPostGetBusinessLogic blogPostGetBusinessLogic;
  private final AuthorGetBusinessLogic authorGetBusinessLogic;
  
  @Inject
  public BlogPostGetApi(
    BlogPostGetBusinessLogic blogPostGetBusinessLogic,
    AuthorGetBusinessLogic authorGetBusinessLogic
  ) {
    this.blogPostGetBusinessLogic = blogPostGetBusinessLogic;
    this.authorGetBusinessLogic = authorGetBusinessLogic;
  }
  
  @Route(
    method = "GET"
    path = "/blog/:id"
  )
  public Response get(String id) throws BlogPostNotFoundException {
    BlogPost blogPost = blogPostGetBusinessLogic.getById(id);
    Author author = authorGetBusinessLogic.getById(blogPost.getAuthorId());
  
    return new Response (
      blogPost,
      author
    )
  }
  
  //Inner class that contains a structured response
  public class Response {
    //...
  }
}

if (!blogPost.isPublished()) {
  throw new BlogPostNotFoundException();
}

業務邏輯
業務邏輯是負責怎麼做的問題，所以你可以有像這樣的類 UserCreateBusinessLogic。此類僅負責導致使用者建立的業務流程。因任何原因需要建立使用者的API都可以依賴於UserCreateBusinessLogic確保使用者建立僅在一個地方完成。
毋庸置疑，業務流程可能變得複雜，因此他們當然可以相互呼叫。例如，如果您有一個建立組織物件的業務流程，並且有一個使用者，那麼您可以擁有一個UserOrganizationRegisterBusinessLogic，它將同時呼叫UserCreateBusinessLogic和OrganizationCreateBusinessLogic。也許還有付款建立和其他幾個。

後端/儲存
我們應用程式中的最後一層負責處理我們應用程式之外的任何討厭部分，例如第三方API，資料庫以及我們認為不可靠的所有其他內容。
等一下......我剛才說資料庫不可靠嗎？Yepp，我剛才是這麼說。資料庫在網路上，並且開發人員希望它與其他人一樣，而網路是不可靠的(banq注：FLP定理)。他們可以損壞，他們可能很慢，他們可以丟包。因此，我對資料庫的處理與處理第三方API的方式相同。
回到API ......通常我們必須處理第三方API，而我們並不是很清楚這些API內部。要麼它沒有被文件描述，要麼它只是有一些我們還沒有遇到過的怪癖。這些將不可避免地導致我們的系統遲早要處理的問題，例如捕獲錯誤，例如，讓業務邏輯現在我無法做到這一點。

例如，資料結構可能很奇怪而且不符合我們的喜好，在這種情況下，後端層作業將其轉換為我們可以工作的物件。

實體
注意：本文不區分實體和DTO。出於本文的目的，實體是您希望在應用程式的各個部分之間傳遞的結構化資料集。如果您想根據目的或用途拆分它們，請選擇它。
正如我提到的，不同的層使用實體進行通訊。這些不是您期望從ORM系統獲得的實體。它們不包含載入子物件的魔術函式，例如blogPost.getAuthor()。這些是啞資料傳輸物件(banq注：可以用DDD實體或值物件實現)，例如：

class BlogPost {
  private final String id;
  private final String authorId;
  private final String title;
  
  public BlogPost(
    String id,
    String authorId,
    String title
  ) {
    this.id = id;
    this.authorId = authorId;
    this.title = title;
  }
  
  public String getId() {
    return this.id;
  }
  
  //...
}

public BlogPost withTitle(
  String title
) {
  return new BlogPost(
    this.id,
    this.authorId,
    title
  );
}

處理一致性
還記得我們上面的組織和使用者註冊示例嗎？一個註冊過程涉及建立多個物件，而這些物件又使用多個儲存類將資料儲存到資料庫。
你如何確保一致性？換句話說，您如何確保建立全部或全部？
這就是Java真正開始閃耀的地方。有一種稱為Java Transaction API的東西，它允許建立分散式事務，甚至可以跨多個資料庫。
我只是Transaction在執行需要它的操作時在我的API層中請求一個物件，然後將它透過我的應用程式傳遞到儲存層。然後，儲存層可以使用它來確保一致性，甚至可以跨多個物件建立/更新。

處理許可權檢查
我很難在很長一段時間內實施更復雜的許可權檢查。API層本身不適合實現廣泛的許可權檢查，因為可能需要跨多個API重用這些許可權。
讓我們舉一個非常簡單的例子：登入的每個使用者都獲得一個訪問令牌，然後你在API中為每個需要許可權的請求請求訪問令牌，如下所示：

public Response update(
  @RequestHeader(name = "Authorization", prefix = "Bearer") 
  String accessToken,
  String blogPostId,
  String title,
  //...
) {
  //...
}

Authorization: Bearer your-access-token-here

public Response update(
  @RequestHeader(name = "Authorization", prefix = "Bearer") 
  String accessToken,
  String blogPostId,
  String title,
  //...
) throws AccessDeniedException, BlogPostNotFoundException {
  newBlogPost = blogPostUpdateSecurity.update(
    blogPostId,
    accessToken,
    title,
    //...
  );
  return new Response(
    newBlogPost
  );
}

傳統的Web應用程式
到目前為止，我們只談到了一個特定於單頁應用程式的架構，其中的東西很簡單。實際上，您的應用程式不必包含任何狀態。它只能傳遞管道中的任何請求並返回結果。從本質上講，您的應用程式基本上是一組函式，通常是純粹的或至少是無狀態的，具有依賴注入。（向JavaScript大家們致敬，我們要感謝近年來函數語言程式設計的興起！）

但是，當談到傳統的Web應用程式時，事情會變得混亂。他們希望在會話中儲存臨時表單資料和一堆其他內容。雖然我不提倡使用會話，但我們必須處理API無需處理的許多事情。
所以，這裡有一個想法：為什麼我們不在API之上再新增一層？畢竟，許可權檢查和所有其他事情已經處理完畢，因此Web層應該只處理傳統Web應用程式特有的內容！

總結

Michael Cullum稱這是Cookie Cutter方法，所以我正式稱之為。基本思路如下：

• 將您的應用程式拆分為服務和實體。
• 實體應該是不可變的，並且只包含驗證程式碼並建立自身的更改副本。(banq注：正是DDD值物件)
• 除了注入的依賴項之外，服務應該沒有內部狀態。
• 服務應該具有非常少量的公共方法，理想情況下只有一種，通常是純粹的或至少是無狀態的 功能。（如果需要，可以新增私有方法以便於閱讀，但通常最好分割整個類。）
• 服務應該儘可能少地處理。儘量讓它們低於〜150行程式碼。
• 應將服務分組為多個層，每個層負責一組任務。

好處
您可能已經意識到，這種架構要求您編寫大量程式碼，尤其是最初的程式碼。它至少不適用於任何類似於快速原型製作方法的東西。
不可否認，我致力於維護週期很長的應用程式，並且經常會收到客戶更改請求。你的情況可能會有所不同，也許你把網站交給你再也見不到的客戶，但是讓我問你：你最後一次走捷徑的時又是什麼時候再次困擾了你？
對我而言，這是最可怕的感受之一，看到客戶提出了一個相對簡單的變更請求，然後導致整個團隊多周頭痛。
這種架構已經證明是一致的。不快，但是一致。我們知道開發某個功能需要多長時間。系統中沒有任何意外，但它帶來的缺點是我們必須自己編寫很多程式碼。
此外，由於此設定不依賴於Java，因此我設法聘請了一位經驗不足的PHP開發人員，並在IDE的幫助下，讓他們在大約3天內提供生產就緒程式碼。
此外，由於一切都非常好並且切割得很好，因此對單個零件進行單元測試非常容易。它使維護起來非常舒適。