用Java11實現整潔架構

簡介

在軟件工程方面，軟件架構是過去幾年中最重要的主題之一。羅伯特·C·馬丁（又名鮑勃叔叔）在他的書中深刻地提出了他對清潔架構的看法，我強烈推薦看看。但是當涉及到實施時，事情變得困難并且出現了許多問題。我從哪里開始？我如何構建我的項目？如何將Bob叔叔的原則應用于我想要使用的技術？我將嘗試從Java Web開發人員的角度回答這些問題，他們希望使用Java 9中的Java 11和Jigsaw模塊。這將為您提供更加具體的視野，讓您了解Uncle Bob的整潔架構。

整潔架構

在實現之前，讓我們來看看架構圖：

圖片.png

Entities(實體) ： 這些是應用程序的業務對象。這些不應受到外部任何更改的影響，這些應該是應用程序中最穩定的代碼。這些可以是POJO或具有方法的對象，甚至是數據結構。
Use Cases(業務用例): 實現并封裝所有業務規則。
Interface Adapters(接口適配器): 將數據轉換并呈現給用例和實體層。
Frameworks and Drivers(框架及驅動): 包含運行應用程序所需的框架或工具。

一些核心概念:

  • 任何層級都只能引用它下面的層級，而不知道上面發生了什么。
  • 業務用例和實體是應用程序的核心，應該具有最小的外部庫依賴項。

實現

開始構建這個項目

我們將使用Gradle多項目和Java Jigsaw模塊來強制執行不同層之間的依賴關系。
我們要構建的應用程序非常簡單，對于這樣的項目來說，該結構可能看起來有點怪，但這是了解這一切是如何工作的最佳方式。
該應用程序的功能主要有：

  • 創建一個用戶
  • 查詢一個用戶
  • 列出所有的用戶
  • 用戶使用自己的密碼進行登錄

為此，我們將從內層（實體/業務用例）開始，然后是接口適配器層，我們將完成外層。我們還將通過更改實現細節和在框架之間切換來演示架構的靈活性。

下面這個是整個項目的整體預覽：


圖片.png

我們開始do it吧。

內層

我們的實體和用例分為兩個子項目：“領域對象”和“業務用例”：


圖片.png

這兩個子項目代表了我們應用的核心。
架構必須非常明確。通過快速查看上面的示例，我們立即知道存在什么樣的操作以及在哪里。如果您要創建單個UserService，則很難說該服務中存在哪些操作，您需要深入了解實現以了解服務的作用。在我們整潔架構中，我們只需要快速查看usecase包，就可以了解支持哪種操作。

在實體包中包含所有實體。在我們的例子中，我們將只有一個，那就是user：

package com.slalom.example.domain.entity;



public class User {



private String id;

private String email;

private String password;

private String lastName;

private String firstName;

// Builder pattern & Getters

// ...

}
usecase子模塊包含我們的業務邏輯。我們將從一個簡單的業務用例FindUser開始：
package com.slalom.example.usecase;



import com.slalom.example.domain.entity.User;

import com.slalom.example.domain.port.UserRepository;

import java.util.List;

import java.util.Optional;



public final class FindUser {



private final UserRepository repository;



// All args constructor



public Optional<User> findById(final String id) {

return repository.findById(id);

}

public List<User> findAllUsers() {

return repository.findAllUsers();

}
}

我們有兩個操作，這兩個操作需要從存儲庫中查詢用戶。這在面向服務的體系結構中看起來很標準。 UserRepository是一個未在我們當前子項目中實現的接口。這被認為是我們架構中的細節，細節在外層實現。當實例化用例時（例如通過依賴注入），將提供它的實現。這提供了一些優點：

  • 無論實現是什么，業務邏輯都保持不變。
  • 實現中的任何更改都不會影響業務邏輯。
  • 完全更改實現非常容易，因為它對業務邏輯沒有影響。

請注意，該接口也稱為端口，因為它構成了業務邏輯和外部世界之間的橋梁。

現在讓我們構建CreateUser用例的第一次迭代。

package com.slalom.example.usecase;



import com.slalom.example.domain.entity.User;

import com.slalom.example.domain.port.IdGenerator;

import com.slalom.example.domain.port.PasswordEncoder;

import com.slalom.example.domain.port.UserRepository;



public final class CreateUser {



private final UserRepository repository;

private final PasswordEncoder passwordEncoder;

private final IdGenerator idGenerator;



// All args constructor



public User create(final User user) {

var userToSave = User.builder()

.id(idGenerator.generate())

.email(user.getEmail())

.password(passwordEncoder.encode(user.getEmail() + user.getPassword()))

.lastName(user.getLastName())

.firstName(user.getFirstName())

.build();

return repository.create(userToSave);

}

}

與FindUser用例一樣，我們需要一個存儲庫，一種生成ID的方法以及一種對密碼進行編碼的方法。這些是細節，而不是業務規則，稍后將在外層實現。

我們還想驗證提供的用戶是否有效（包含正確的數據）并且它在數據庫中不存在。這導致了我們對用例的最后一次迭代：

package com.slalom.example.domain.usecase;



import com.slalom.example.domain.entity.User;

import com.slalom.example.domain.exception.UserAlreadyExistsException;

import com.slalom.example.domain.port.IdGenerator;

import com.slalom.example.domain.port.PasswordEncoder;

import com.slalom.example.domain.port.UserRepository;

import com.slalom.example.domain.usecase.validator.UserValidator;



public final class CreateUser {



private final UserRepository repository;

private final PasswordEncoder passwordEncoder;

private final IdGenerator idGenerator;



// All args constructor



public User create(final User user) {

UserValidator.validateCreateUser(user);

if (repository.findByEmail(user.getEmail()).isPresent()) {

throw new UserAlreadyExistsException(user.getEmail());

}

var userToSave = User.builder()

.id(idGenerator.generate())

.email(user.getEmail())

.password(passwordEncoder.encode(user.getEmail() + user.getPassword()))

.lastName(user.getLastName())

.firstName(user.getFirstName())

.build();

return repository.create(userToSave);

}

}

如果用戶無效或已存在，則拋出自定義運行時異常。這些自定義異常應由其他層處理。

我們的最后一個用例LoginUser非常簡單，可以在GitHub中使用。

最后，為了強制執行邊界，兩個子項目都使用Jigsaw模塊。 Jigsaw模塊允許我們僅向外界公開需要暴露的內容，因此不會泄露任何實現細節。例如，沒有理由公開UserValidator類：

// Domain module-info

module slalom.example.domain {

exports com.slalom.example.domain.entity;

exports com.slalom.example.domain.port;

exports com.slalom.example.domain.exception;

}



// Use case module-info

module slalom.example.usecase {

exports com.slalom.example.usecase;

requires slalom.example.domain;

requires org.apache.commons.lang3;

}
總結一下內層的作用：
  • 內層包含領域對象和業務規則。這應該是應用程序中最穩定和最應該測試的部分。
  • 內部層中沒有實現與外部世界的任何交互（如數據庫或外部服務）。我們使用端口（接口）來表示它們。
  • 沒有使用框架和最小的依賴關系。
  • Jigsaw模塊允許我們隱藏實現細節。

外層

適配器

現在我們有了實體和業務用例，我們可以實現細節。為了能夠證明該體系結構非常靈活，我們將創建多個實現并在不同的上下文中使用它們。


圖片.png

讓我們從倉儲開始弄吧。
使用簡單HashMap的UserRepository實現：

package com.slalom.example.db;

import com.slalom.example.domain.entity.User;
import com.slalom.example.domain.port.UserRepository;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Optional;

public class InMemoryUserRepository implements UserRepository {
    
    private final Map<String, User> inMemoryDb = new HashMap<>();
    
    @Override
    public User create(final User user) {
        inMemoryDb.put(user.getId(), user);
        return user;
    }
  
    @Override
    public Optional<User> findById(final String id) {
        return Optional.ofNullable(inMemoryDb.get(id));
    }
  
    @Override
    public Optional<User> findByEmail(final String email) {
        return inMemoryDb.values().stream()
            .filter(user -> user.getEmail().equals(email))
            .findAny();
    }
  
    @Override
    public List<User> findAllUsers() {
        return new ArrayList<>(inMemoryDb.values());
    }
}

你也可以在GitHub上找到Hazelcast的另一個實現。

其他適配器：

其他適配器可以使用領域對象中聲明的接口相同的方式來實現。你可以在GitGub上找到它們：
密碼封裝器
Jug ID生成器
UUID生成器

將所有的組件組合在一起

現在我們已經有了實現細節，我們需要將它們組合在一起。為此，我們需要創建一個包含應用程序配置的config文件夾和一個包含運行應用程序代碼的應用程序文件夾。
下面是他們的配置信息：

public class ManualConfig {

    private final UserRepository userRepository = new InMemoryUserRepository();
    private final IdGenerator idGenerator = new JugIdGenerator();
    private final PasswordEncoder passwordEncoder = new Sha256PasswordEncoder();

    public CreateUser createUser() {
        return new CreateUser(userRepository, passwordEncoder, idGenerator);
    }
    
    public FindUser findUser() {
        return new FindUser(userRepository);
    }
    
    public LoginUser loginUser() {
        return new LoginUser(userRepository, passwordEncoder);
    }
}

此配置使用相關適配器初始化用例。如果您想要更改實現，您可以輕松地從一個適配器實現切換到另一個，而無需修改用例代碼。

下面是運行應用程序的類：

public class Main {
    public static void main(String[] args) {
        // Setup
        var config = new ManualConfig();
        var createUser = config.createUser();
        var findUser = config.findUser();
        var loginUser = config.loginUser();
        var user = User.builder()
            .email("john.doe@gmail.com")
            .password("mypassword")
            .lastName("doe")
            .firstName("john")
            .build();
                        
        // Create a user
        var actualCreateUser = createUser.create(user);
        System.out.println("User created with id " + actualCreateUser.getId());
                
        // Find a user by id
        var actualFindUser = findUser.findById(actualCreateUser.getId());
        System.out.println("Found user with id " + actualFindUser.get().getId());
                
        // List all users
        var users = findUser.findAllUsers();
        System.out.println("List all users: " + users);
                
        // Login
        loginUser.login("john.doe@gmail.com", "mypassword");
        System.out.println("Allowed to login with email 'john.doe@gmail.com' and password 'mypassword'");
    }
}

Web 框架

  • 如果您想使用Spring Boot或Vert.x等Web框架，該怎么辦？這很簡單 - 我們只需要：
  • 為Web應用程序創建新配置。
  • 創建一個新的應用程序運行器。
  • 在適配器文件夾中添加Controller。Controller將負責與內層通信。
    這是Spring Controller的例子：
package com.slalom.example.spring.controller;

@RestController
public class UserController {
    private final CreateUser createUser;
    private final FindUser findUser;
    private final LoginUser loginUser;
  
    // All args constructor with @Autowired
  
    @RequestMapping(value = "/users", method = RequestMethod.POST)
    public UserWeb createUser(@RequestBody final UserWeb userWeb) {
        var user = userWeb.toUser();
        return UserWeb.toUserWeb(createUser.create(user));
    }
    
    @RequestMapping(value = "/login", method = RequestMethod.GET)
    public UserWeb login(@RequestParam("email") final String email, @RequestParam("password") final String password) {
        return UserWeb.toUserWeb(loginUser.login(email, password));
    }
    
    @RequestMapping(value = "/users/{userId}", method = RequestMethod.GET)
    public UserWeb getUser(@PathVariable("userId") final String userId) {
        return UserWeb.toUserWeb(findUser.findById(userId).orElseThrow(() -> new RuntimeException("user not found")));
    }
    
    @RequestMapping(value = "/users", method = RequestMethod.GET)
    public List<UserWeb> allUsers() {
        return findUser.findAllUsers()
            .stream()
            .map(UserWeb::toUserWeb)
            .collect(Collectors.toList());
    }
}

您可以使用Spring Boot和Vert.x在GitHub中找到此應用程序的完整示例。

總結：

我們在本文中試圖展示Uncle Bob的整潔架構是多么強大。希望現在你有點清楚這個玩意兒了。

優點：

Power：您的業務邏輯是受到保護的，外部任何東西都無法使其失敗。您的代碼不依賴于任何外部框架。
Flexibility(靈活性)：任何適配器都可以隨時由您選擇的任何其他實現來進行替換。從Spring啟動切換到Vert.x或Dropwizard可以非常快速地完成。
Defer decisions(延遲決定)：我需要什么數據庫？我需要什么樣的Web框架？您可以在不了解這些細節的情況下構建業務邏輯。
High maintainability(強大的可維護性): 很容易識別哪個組件出現故障。
Implement faster(快速實現): 由于架構將問題分開，您可以一次專注于一項任務并更快地發展。這也應該減少技術債務的數額。
Tests(測試): 單元測試更容易，因為依賴關系是明確定義的，它很容易模擬測試。
Integration tests(集成測試): 您可以在集成測試期間創建要訪問的任何外部服務的自定義實現。例如，如果您不希望因為按請求付費而訪問云中托管的數據庫，只需使用適配器中的內存實現即可。

缺點:

Learning curve(學習曲線)，一開始架構可能會非常龐大，尤其對是初級開發人員不友好。
更多類，更多包，更多子項目。據我所知，沒有什么可以做的。作為一名polygot開發人員，我鼓勵Java開發人員探索其他語言，如Kotlin。在這種情況下，Kotlin可以幫助減少創建的文件數量。
使項目的復雜性變得更高。
對于小型項目來說，這可能只是過度設計。

GitHub上的項目提供了有關如何處理Web框架的更多詳細信息。如果您有興趣，我會鼓勵您查看代碼并使用它。

原文地址：https://medium.com/slalom-engineering/clean-architecture-with-java-11-f78bba431041

最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
    沈念sama閱讀 228,412評論 6贊 532
  • 死咒
    序言：濱河連續發生了三起死亡事件，死亡現場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發現死者居然都...
    沈念sama閱讀 98,514評論 3贊 416
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
    開封第一講書人閱讀 176,373評論 0贊 374
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長。 經常有香客問我，道長，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 62,975評論 1贊 312
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當我...
    茶點故事閱讀 71,743評論 6贊 410
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上，一...
    開封第一講書人閱讀 55,199評論 1贊 324
  • 城市分裂傳說
    那天，我揣著相機與錄音，去河邊找鬼。 笑死，一個胖子當著我的面吹牛，可吹牛的內容都是我干的。 我是一名探鬼主播，決...
    沈念sama閱讀 43,262評論 3贊 441
  • 雙鴛鴦連環套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起，我...
    開封第一講書人閱讀 42,414評論 0贊 288
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當地人在樹林里發現了一具尸體，經...
    沈念sama閱讀 48,951評論 1贊 336
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,780評論 3贊 354
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,983評論 1贊 369
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 38,527評論 5贊 359
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質發生泄漏。R本人自食惡果不足惜，卻給世界環境...
    茶點故事閱讀 44,218評論 3贊 347
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,649評論 0贊 26
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監牢的瞬間，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,889評論 1贊 286
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。 一個月前我還...
    沈念sama閱讀 51,673評論 3贊 391
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 47,967評論 2贊 374