628 lines
30 KiB
Markdown
628 lines
30 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
075 案例 领域设计模型的价值
|
||
在领域驱动设计过程中，正确地进行领域建模是至为关键的环节。如果我们没有能够从业务需求中发现正确的领域概念，就可能导致职责的分配不合理，业务流程不清晰，出现没有任何领域行为的贫血对象，甚至做出错误的设计决策。
|
||
|
||
错误的设计
|
||
|
||
在一个航延结算系统中，业务需求要求导入一个结算账单模板的 Excel 文档，然后通过账单号查询该模板需要填充的变量值，生成并导出最终需要的结算账单。结算账单有多种，如内部结算账单等。不同账单的模板并不相同，需要填充的变量值也不相同。
|
||
|
||
团队对此进行了领域建模，识别了表达领域概念的领域模型对象，包括：
|
||
|
||
|
||
InternalSettlementBill
|
||
TemplateReplacement
|
||
BaseBillReviewExportTemplate
|
||
InternalSettlementBillService
|
||
BillReviewService
|
||
|
||
|
||
在这些对象中，InternalSettlementBill 被定义为实体类，TemplateReplacement 被定义为值对象。由于存在多种结算账单，实现时考虑了代码的可扩展与重用，在设计模型中引入了模板方法模式改进领域模型，即引入的 BaseBillReviewExportTemplate。注意，该抽象类命名中包含的 Template 并非结算账单模板，而是为了体现它运用了模板方法模式。同时，还定义了领域服务 InternalSettlementBillService 和 BillReviewService。它们之间的关系如下所示：
|
||
|
||
|
||
|
||
实现代码为：
|
||
|
||
package settlement.domain;
|
||
|
||
import lombok.Data;
|
||
|
||
@Data
|
||
public class InternalSettlementBill {
|
||
private String billNumber;
|
||
private String flightIdentity;
|
||
private String flightNumber;
|
||
private String flightRoute;
|
||
private String scheduledDate;
|
||
private String passengerClass;
|
||
private List<Passenger> passengers;
|
||
private String serviceReason;
|
||
private List<CostDetail> costDetails;
|
||
private BigDecimal totalCost;
|
||
}
|
||
|
||
package settlement.infrastructure.file;
|
||
|
||
import lombok.data;
|
||
import lombok.AllArgsConstructor;
|
||
|
||
@Data
|
||
@AllArgsConstructor
|
||
public class TemplateReplacement {
|
||
private int rowIndex;
|
||
private int cellNum;
|
||
private String replaceValue;
|
||
}
|
||
|
||
pakcage settlement.domain;
|
||
|
||
import settlement.infrastructure.file.TemplateReplacement;
|
||
|
||
abstract class BaseBillReviewExportTemplate<T> {
|
||
public final List<TemplateReplacement> queryAndComposeTemplateReplacementsBy(String billNumber) {
|
||
T t = queryFilledDataBy(billNumber);
|
||
return composeTemplateReplacements(t);
|
||
}
|
||
|
||
protected abstract T queryFilledDataBy(String billNumber);
|
||
protected abstract List<TemplateReplacement> composeTemplateReplacements(T t);
|
||
}
|
||
|
||
pakcage settlement.domain;
|
||
|
||
import settlement.infrastructure.file.TemplateReplacement;
|
||
import org.springframework.stereotype.Service;
|
||
import javax.annotation.Resource;
|
||
|
||
@Service
|
||
public class InternalSettlementBillService extends BaseBillReviewExportTemplate<InternalSettlementBill> {
|
||
@Resource
|
||
private InternalSettlementBillRepository internalSettlementBillRepository;
|
||
|
||
@Override
|
||
protected InternalSettlementBill queryFilledDataBy(String billNumber) {
|
||
return internalSettlementBillRepository.queryByBillNumber(billNumber);
|
||
}
|
||
|
||
@Override
|
||
protected List<TemplateReplacement> composeTemplateReplacements(InternalSettlementBill t) {
|
||
List<TemplateReplacement> templateReplacements = new ArrayList<>();
|
||
templateReplacements.add(new TemplateReplacement(0, 0, t.getBillNumber()));
|
||
templateReplacements.add(new TemplateReplacement(1, 0, t.getFlightIdentity()));
|
||
templateReplacements.add(new TemplateReplacement(1, 2, t.getFlightRoute()));
|
||
return templateReplacements;
|
||
}
|
||
}
|
||
|
||
package settlement.domain;
|
||
|
||
import settlement.infrastructure.file.FileDownloader;
|
||
import settlement.infrastructure.file.PoiUtils;
|
||
import settlement.infrastructure.file.TemplateReplacement;
|
||
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
import org.springframework.beans.factory.annotation.Value;
|
||
import org.springframework.stereotype.Service;
|
||
import javax.annotation.Resource;
|
||
import javax.servlet.http.HttpServletResponse;
|
||
|
||
@Service
|
||
public class BillReviewService {
|
||
private static final String DEFAULT_REPLACE_PATTERN = "@replace";
|
||
private static final int DEFAULT_SHEET_INDEX = 0;
|
||
|
||
@Value("${file-path.bill-templates-dir}")
|
||
private String billTemplatesDirPath;
|
||
|
||
@Resource
|
||
private PoiUtils poiUtils;
|
||
@Resource
|
||
private FileDownloader fileDownloader;
|
||
@Resource
|
||
private InternalSettlementBillService internalSettlementBillService;
|
||
@Resource
|
||
private ExportBillReviewConfiguration configuration;
|
||
|
||
public void exportBillReviewByTemplate(HttpServletResponse response, String billNumber, String templateName) {
|
||
try {
|
||
String className = fetchClassNameFromConfigBy(templateName);
|
||
List<TemplateReplacement> replacements = templateReplacementsBy(billNumber, className);
|
||
|
||
HSSFWorkbook workbook = poiUtils.getHssfWorkbook(billTemplatesDirPath + templateName);
|
||
poiUtils.fillCells(workbook, DEFAULT_SHEET_INDEX, DEFAULT_REPLACE_PATTERN, replacements);
|
||
|
||
fileDownloader.downloadHSSFFile(response, workbook, templateName);
|
||
} catch (Exception e) {
|
||
logger.error("Export bill review by template failed, templateName: {}", templateName);
|
||
e.printStackTrace();
|
||
}
|
||
}
|
||
|
||
private List<TemplateReplacement> templateReplacementsBy(String billNumber, String className) {
|
||
switch (className) {
|
||
case "InternalSettlementBill":
|
||
return internalSettlementBillService.queryAndComposeTemplateReplacementsBy(billNumber);
|
||
default:
|
||
return null;
|
||
}
|
||
}
|
||
|
||
private String fetchClassNameFromConfigBy(String templateName) throws Exception {
|
||
for (ExportBillReviewConfiguration.Item item : configuration.getItems()) {
|
||
if (item.getTemplateName().equals(templateName)) {
|
||
return item.getClassName();
|
||
}
|
||
}
|
||
throw new Exception("can not found className by templateName in configuration file");
|
||
}
|
||
}
|
||
|
||
package com.caacetc.bigdata.fdss.infrastructure.file;
|
||
|
||
import java.io.File;
|
||
import java.io.FileInputStream;
|
||
import java.io.FileOutputStream;
|
||
import java.io.IOException;
|
||
import java.util.List;
|
||
|
||
import com.google.common.base.Preconditions;
|
||
import org.apache.poi.hssf.usermodel.HSSFCell;
|
||
import org.apache.poi.hssf.usermodel.HSSFSheet;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
import org.apache.poi.poifs.filesystem.POIFSFileSystem;
|
||
|
||
public class PoiUtils {
|
||
public static HSSFWorkbook getHSSFWorkbook(String filePath) throws IOException {
|
||
File file = new File(filePath);
|
||
POIFSFileSystem fs = new POIFSFileSystem(new FileInputStream(file));
|
||
return new HSSFWorkbook(fs);
|
||
}
|
||
|
||
public static void fillCells(HSSFWorkbook hssfWorkbook, int sheetIndex, String replacePattern, List<TemplateVariable> variables) {
|
||
Preconditions.checkNotNull(hssfWorkbook);
|
||
Preconditions.checkNotNull(variables);
|
||
|
||
HSSFSheet sheet = hssfWorkbook.getSheetAt(sheetIndex);
|
||
|
||
for (TemplateVariable variable : variables) {
|
||
HSSFCell cell = sheet.getRow(variable.getRowIndex()).getCell(variable.getCellNum());
|
||
|
||
String originalValue = cell.getStringCellValue();
|
||
String replaceValue = variable.getReplaceValue();
|
||
|
||
if (replaceValue == null) {
|
||
continue;
|
||
}
|
||
|
||
if (originalValue.toLowerCase().contains(replacePattern)) {
|
||
cell.setCellValue(originalValue.replace(replacePattern, replaceValue));
|
||
} else {
|
||
cell.setCellValue(replaceValue);
|
||
}
|
||
}
|
||
}
|
||
|
||
public static void writeToFile(HSSFWorkbook hssfWorkbook, String filePath, String fileName) throws IOException {
|
||
FileOutputStream out = new FileOutputStream(filePath + fileName);
|
||
hssfWorkbook.write(out);
|
||
out.close();
|
||
out.flush();
|
||
}
|
||
}
|
||
|
||
|
||
|
||
问题分析
|
||
|
||
仔细分析前面的领域设计模型，再通过阅读具体的实现代码，我们发现上述设计与实现体现了在领域建模过程中存在的如下问题：
|
||
|
||
|
||
贫血模型：InternalSettlementBill 实体表现了“内部结算账单”的领域概念，但与它相关的业务行为都分给了和该实体对应的领域服务中。
|
||
领域概念含混不清，没有制定统一语言：例如 BaseBillReviewExportTemplate 类的命名，蕴含了多个概念 bill、review、export。究竟要做什么？账单（bill）与评阅（review）是什么关系？是导出账单的评阅？还是导出账单与评阅？系统中本有模板（template）领域概念，现在又将设计模式中的模板方法（template method）混淆在一起，容易让人产生误解。
|
||
领域模型按照实现逻辑而非业务逻辑命名：从命名的字面含义理解，值对象 TemplateReplacement 表达了模板替换的概念，目的为替换模板的真实值，但从模板的业务角度考虑，其实是模板的变量，即 TemplateVariable。
|
||
层次不清，职责分配混乱：值对象 TemplateReplacement 是结算账单处理领域中的概念，却被放到了基础设施层，因为 PoiUtils 要访问它；领域层中的领域服务 BillReviewService 又与基础设施层中针对 Excel 文件的操作纠缠在一起，且依赖了 Servlet 框架的 HttpServletResponse 类。
|
||
|
||
|
||
表面看来，这些问题都是设计缺陷，但其根由还是在于我们并没有正确地建立领域分析和设计模型。含混的领域概念导致了职责和层次的混乱，没有清晰地传递业务逻辑。如果任其发展下去，这样的代码实现模型会随着需求的逐渐增加而变得越来越难以维护，所谓的“领域驱动设计”最终就会变成一句空话。
|
||
|
||
改进设计
|
||
|
||
设计改进从理清需求开始
|
||
|
||
怎么改进呢？让我们首先回到领域驱动设计的核心，即从领域角度理解系统的业务需求。通过和团队成员沟通需求，我了解到的业务流程为：
|
||
|
||
|
||
用户首先导入一个结算账单模板的 Excel 工作薄；
|
||
Excel 工作薄模板中对应的单元格中定义了一些变量值，系统需要从数据库中读取结算账单的信息，然后基于模板单元格的坐标，将模板中的变量替换为结算账单信息中的值；
|
||
导出替换了变量值的 Excel 工作薄。
|
||
|
||
|
||
根据该业务流程，可以识别出如下职责：
|
||
|
||
|
||
导入结算账单模板
|
||
获取结算账单模板变量值
|
||
基于模板变量填充结算账单模板，生成结算账单
|
||
导出结算账单
|
||
|
||
|
||
通过分析这些职责，尤其关注职责中描述的领域概念，并识别职责的履行者，可以获得如下所示的领域模型：
|
||
|
||
|
||
|
||
对比前后两个领域模型，我引入了 SettlementBillTemplate 对象，由它代表结算账单模板。这里要特别注意区分结算账单（SettlementBill）和结算账单模板（SettlementBillTemplate）两个概念。模板规定了结算账单填充数据的内容和格式，不同的结算账单会有不同的模板。一旦填充了模板变量值后，就会形成结算账单。虽然从领域概念上讲，结算账单有多种类别，如内部结算账单、交易结算账单等。但这个区别主要体现在模板上，因为它决定了结算账单要填充的值，至于结算账单本身是没有任何区别的。因此，在导出结算账单这个业务场景中，不同账单的区别就体现在模板和模板变量值上。模板和模板变量放在同一个聚合中。可以为模板定义如下的继承体系，继承体系中的每个子类为一个独立的聚合：
|
||
|
||
|
||
|
||
避免贫血模型
|
||
|
||
一旦理清了需求，就可以获得正确的领域分析模型与设计模型。每个领域模型对象都体现了领域知识，也可以让我们根据它们所拥有的数据合理分配职责。在前面给出的领域设计模型中，一个模板可以包含多个模板变量，模板变量的值就来自这个作为主体的模板实体对象。每个模板对象自身了解自己的变量是哪些，该如何组装这些模板变量。根据“信息专家模式”，这个组装模板变量的功能就该分配给模板实体，而非之前模型中的 InternalSettlementBillService 服务。转移职责后的 InternalSettlementBillTemplate 实体定义如下：
|
||
|
||
package settlement.domain;
|
||
|
||
public interface SettlementBillTemplate {
|
||
List<TemplateVariable> composeVariables();
|
||
}
|
||
|
||
package settlement.domain;
|
||
|
||
@Data
|
||
public class InternalSettlementBillTemplate implements SettlementBillTemplate {
|
||
private String billNumber;
|
||
private String flightIdentity;
|
||
private String flightNumber;
|
||
private String flightRoute;
|
||
private String scheduledDate;
|
||
private String passengerClass;
|
||
private List<Passenger> passengers;
|
||
private String serviceReason;
|
||
private List<CostDetail> costDetails;
|
||
private BigDecimal totalCost;
|
||
|
||
public List<TemplateVariable> composeVariables() {
|
||
return Lists.newArrayList(
|
||
new TemplateVariable(0, 0, this.billNumber),
|
||
new TemplateVariable(1, 0, this.flightIdentity),
|
||
new TemplateVariable(1, 2, this.flightRoute)
|
||
);
|
||
}
|
||
}
|
||
|
||
|
||
|
||
我们并非为了避免 InternalSettlementBillTemplate 成为贫血对象而硬塞一个领域行为给它，而是从职责分配的角度来考虑的。看看这里的 composeVariables() 方法的实现，如 billNumber、flightIdentity 和 flightRoute 就是它自己拥有的，为何还要假手于一个不拥有这些数据的服务呢？
|
||
|
||
在领域纯粹性与实现简便性之间权衡
|
||
|
||
InternalSettlementBillTemplate 仅仅完成了模板变量的组装，对于“填充结算账单模板生成结算账单”职责而言，又该谁来承担呢？从职责描述看，其实这里牵涉到两个领域对象：结算账单模板和结算账单。结算账单模板仅提供填充的值，如何生成结算账单，按理说是结算账单的事情。对比前面识别出来的业务流程和职责，业务流程中反复提到的 Excel 工作薄，在职责描述中都被抹去了，因为 Excel 工作薄其属于技术实现细节。我们要完成的业务功能是填充结算账单模板与导出结算账单，而不是填充 Excel 工作薄的单元格，自然也不是下载 Excel 工作薄文件。因此，依据领域驱动设计思想，提炼出的 SettlementBill 实体就应该封装这些实现细节。在理想状态下，这些领域实体暴露的接口不允许出现所谓的 Excel 工作薄，也就是前面代码中引入的 POI 框架中的 HSSFWorkbook 对象。在进行领域分析建模和设计建模时，应尽量摈弃实现细节，单从业务角度去分析和设计。基于这样的建模思想，我们就将“填充结算账单模板生成结算账单”职责分配给 SettlementBill 对象：
|
||
|
||
public class SettlementBill {
|
||
public void fillWith(SettlementBillTemplate template) { }
|
||
}
|
||
|
||
|
||
|
||
这样的代码直观地体现了领域逻辑：通过结算账单模板进行填充，最终得到结算账单自身。确定了接口，实际上就是确定了领域对象之间的协作关系。接下来，再来思考实现。
|
||
|
||
若要保障设计的纯粹性，SettlementBill 就应该与 Excel 工作薄完全无关，它包含的就是最终生成的结算账单需要的数据。至于该账单究竟是 Excel，还是别的其他格式，其实是账单表现形式（Representation）的区别。它们之间的关系有点类似 model 与 view 的关系。如果要考虑未来的扩展，例如账单导出为 PDF 或展现为 HTML 格式，则有必要将结算账单实体与承载账单的表现形式解耦合。
|
||
|
||
可惜，这样的设计面临实现细节的窘境！若 SettlementBill 为纯粹的领域对象，要导出为 Excel 格式的结算账单，就需要记录账单所有值在工作薄中的坐标，以便于在生成模板文件时正确地填充值。然而，该账单的部分值其实在导入的工作薄文件中已经存在，再做一次无谓的填充就显得多余了。就目前了解的客户需求，也并无导出其他格式结算账单的特性。为此，我们在实现的简便性、领域模型的纯粹性以及未来功能的可扩展性多个方面做了取舍，不得已做出一个设计妥协，即直接将 POI 框架的 HSSFWorkbook 作为结算账单对象内部持有的属性。领域层依赖 POI 框架使得我们的领域模型不再纯粹，但为了技术实现的便利性，偶尔退让一步，也未为不可，只要我们能守住底线——保持系统架构的清晰层次。
|
||
|
||
于是，SettlementBill 的实现就变为：
|
||
|
||
package settlement.domain;
|
||
|
||
import org.apache.poi.hsf.usermodel.*;
|
||
|
||
public class SettlementBill {
|
||
private HSSFWorkbook workbook;
|
||
private int sheetIndex;
|
||
private String replacePattern;
|
||
|
||
public SettlementBill(HSSFWorkbook workbook) {
|
||
this(workbook, 0, "@replace");
|
||
}
|
||
|
||
public SettlementBill(HSSFWorkbook workbook, int sheetIndex, String replacePattern) {
|
||
this.workbook = workbook;
|
||
this.sheetIndex = sheetIndex;
|
||
this.replacePattern = replacePattern;
|
||
}
|
||
|
||
public HSSFWorkbook getWorkbook() {
|
||
return this.workbook;
|
||
}
|
||
|
||
public void fillWith(SettlementBillTemplate template) {
|
||
HSSFSheet sheet = hssfWorkbook.getSheetAt(sheetIndex);
|
||
template.composeVariables().foreach( v -> {
|
||
HSSFCell cell = sheet.getRow(v.getRowIndex()).getCell(v.getCellNum());
|
||
String cellValue = cell.getStringCellValue();
|
||
String replaceValue = v.getReplaceValue();
|
||
if (replaceValue == null) {
|
||
logger.warn("{} -> {} 替换值为空，未从数据库中查出相应字段值", cellValue, replaceValue);
|
||
continue;
|
||
}
|
||
logger.info("{} -> {}", cellValue, replaceValue);
|
||
|
||
if (cellValue.toLowerCase().contains(replacePattern)) {
|
||
cell.setCellValue(cellValue.replace(replacePattern, replaceValue));
|
||
} else {
|
||
cell.setCellValue(replaceValue);
|
||
}
|
||
});
|
||
}
|
||
}
|
||
|
||
|
||
|
||
有些遗憾，系统的 Domain 层依赖了 Apache 的 POI 框架。要解除这种耦合并非不能做到，例如可以针对 HSSFWorkbook、HSSFSheet 以及 HSSFCell 等一系列 POI 框架的对象进行抽象。这一设计固然可以解除对框架的耦合，但在当前场景下，却有过度设计的嫌疑。白玉微瑕，好在我们仍然走在正确的领域建模的道路上。
|
||
|
||
引入领域服务
|
||
|
||
现在考虑结算账单的导出。谁该拥有导出模板的能力呢？虽然要导出的数据是 SettlementBill 拥有的，但它并不具备读取与下载工作薄文件的能力，既然如此，就只能将其放到领域服务。你看，我在分配领域逻辑的职责时，是将领域服务排在最后的顺序。改进了的领域设计模型中已经给出了承担这一职责的领域对象，那就是 SettlementBillExporter 领域服务。注意，我并没有笼统将该服务命名为 SettlementBillService，而是依据“导出”职责命名为 Exporter，体现了它扮演的角色，或者说它具备导出的能力：
|
||
|
||
package settlement.domain;
|
||
|
||
import settlement.domain.exceptions.SettlementBillFileFailedException;
|
||
import settlement.repositories.SettlementBillRepository;
|
||
import settlement.interfaces.file.WorkbookReader;
|
||
import settlement.interfaces.file.WorkbookWriter;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
|
||
import javax.servlet.http.HttpServletResponse;
|
||
|
||
public class SettlementBillTemplateExporter {
|
||
@Service
|
||
private WorkbookReader reader;
|
||
@Service
|
||
private WorkbookWriter writer;
|
||
@Repository
|
||
private SettlementBillRepository repository;
|
||
|
||
public void export(HttpServletResponse response, String templateName, String billNumber) {
|
||
|
||
try {
|
||
SettlementBillTemplate billTemplate = repository.templateBy(templateName, billNumber);
|
||
HSSFWorkbook workbook = reader.readFrom(templateName);
|
||
SettlementBill bill = new SettlementBill(workbook);
|
||
bill.fillWith(billTemplate);
|
||
writer.writeTo(response, bill, templateName);
|
||
} catch (FailedToReadFileException | FailedToWriteFileException ex) {
|
||
throw new SettlementBillFileFailedException(ex.getMessage(), ex);
|
||
}
|
||
}
|
||
}
|
||
|
||
|
||
|
||
我将 WorkbookReader 和 WorkbookWriter 赋给了该领域服务，使其具备了读取与下载工作薄的能力。这是两个抽象的接口。因为它们的实现是读写 Excel 文件，访问了外部资源，属于“南向网关”，因此要遵循整洁架构思想，对其进行抽象，以分离业务逻辑与技术实现。
|
||
|
||
隔离业务逻辑与技术实现
|
||
|
||
什么是业务逻辑？组装模板变量，填充结算账单模板以及导出结算账单都是业务逻辑。什么是技术实现？读写 Excel 工作薄文件就是技术实现。既然如此，工作薄文件的读写职责就应该分配给基础设施层。如下的接口定义放在 interfaces/file 包中，实现放在 gateways/file 包中：
|
||
|
||
package settlement.interfaces.file;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
|
||
public interface WorkbookReader {
|
||
HSSFWorkbook readFrom(String templateName) throws FailedToReadFileException;
|
||
}
|
||
|
||
package settlement.interfaces.file;
|
||
import javax.servlet.http.HttpServletResponse;
|
||
|
||
public interface WorkbookWriter {
|
||
void writeTo(HttpServletResponse response, SettlementBill bill, String templateName) throws FailedToWriteFileException;
|
||
}
|
||
|
||
package settlement.gateways.file;
|
||
import settlement.interfaces.file.WorkbookReader;
|
||
import settlement.interfaces.file.FailedToReadFileException;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
|
||
public class ExcelWorkbookReader implements WorkbookReader {}
|
||
|
||
package settlement.gateways.file;
|
||
import settlement.interfaces.file.WorkbookWriter;
|
||
import settlement.interfaces.file.FailedToReadFileException;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
import javax.servlet.http.HttpServletResponse;
|
||
|
||
public class ExcelWorkbookWriter implements WorkbookWriter {}
|
||
|
||
|
||
|
||
在定义 SettlementBillExporter 时，除了无法避免对 POI 框架的依赖之外，我还发现了它不幸地依赖了 Servlet 框架。因为在导出结算账单时，需要通过 HttpServletReponse 对象获得 OutputStream，然后作为输出流交给结算账单中包含的工作薄：
|
||
|
||
public class ExcelWorkbookWriter implements WorkbookWriter {
|
||
public void writeTo(HttpServletResponse response, SettlementBill bill, String templateName) throws FailedToWriteFileException {
|
||
try {
|
||
OutputStream os = response.getOutputStream();
|
||
bill.getWorkbook().write(os);
|
||
setResponseProperties(response, fileName);
|
||
} catch (IOException ex) {
|
||
ex.printStackTrace();
|
||
throw new FailedToWriteFileException(ex.getMessage(), ex);
|
||
} finnaly {
|
||
if (os != null) {
|
||
os.close();
|
||
}
|
||
}
|
||
}
|
||
}
|
||
|
||
|
||
|
||
这很糟糕！作为封装业务逻辑的领域层，不应该依赖处理 Web 请求的 Servlet 包。分析导出功能的实现代码，其实它仅仅用到了 HttpServletResponse 对象的 getOutputStream() 方法，返回的 OutputStream 对象则是 JDK 中 java.io 库中的一个类。既然如此，我们就可以在领域层为其建立抽象，例如定义接口 OutputStreamProvider：
|
||
|
||
package settlement.domain;
|
||
import java.io.OutputStream;
|
||
|
||
public interface OutputStreamProvider {
|
||
OutputStream outputStream();
|
||
}
|
||
|
||
|
||
|
||
领域服务可以使用在领域层中定义的 OutputStreamProvider 抽象：
|
||
|
||
package settlement.domain;
|
||
|
||
import settlement.domain.exceptions.SettlementBillFileFailedException;
|
||
import settlement.interfaces.file.FailedToReadFileException;
|
||
import settlement.interfaces.file.FailedToWriteFileException;
|
||
import settlement.repositories.SettlementBillRepository;
|
||
import settlement.interfaces.file.WorkbookReader;
|
||
import settlement.interfaces.file.WorkbookWriter;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
|
||
public class SettlementBillTemplateExporter {
|
||
@Service
|
||
private WorkbookReader reader;
|
||
@Service
|
||
private WorkbookWriter writer;
|
||
@Repository
|
||
private SettlementBillRepository repository;
|
||
|
||
public void export(OutputStreamProvider streamProvider, String templateName, String billNumber) {
|
||
try {
|
||
SettlementBillTemplate billTemplate = repository.templateBy(templateName, billNumber);
|
||
HSSFWorkbook workbook = reader.readFrom(templateName);
|
||
SettlementBill bill = new SettlementBill(workbook);
|
||
bill.fillWith(billTemplate);
|
||
writer.writeTo(streamProvider, bill, templateName);
|
||
} catch (FailedToReadFileException | FailedToWriteFileException ex) {
|
||
throw new SettlementBillFileFailedException(ex.getMessage(), ex);
|
||
}
|
||
}
|
||
}
|
||
|
||
|
||
|
||
当然，WorkbookWriter 接口与其实现的定义也随之进行调整：
|
||
|
||
package settlement.interfaces.file;
|
||
import settlement.domain.OutputStreamProvider;
|
||
|
||
public interface WorkbookWriter {
|
||
void writeTo(OutputStreamProvider streamProvider, SettlementBill bill, String templateName) throws FailedToWriteFileException;
|
||
}
|
||
|
||
package settlement.gateways.file;
|
||
import settlement.interfaces.file.WorkbookWriter;
|
||
import settlement.interfaces.file.FailedToReadFileException;
|
||
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
|
||
|
||
public class ExcelWorkbookWriter implements WorkbookWriter {
|
||
public void writeTo(OutputStreamProvider streamProvider, SettlementBill bill, String templateName) throws FailedToWriteFileException {}
|
||
}
|
||
|
||
|
||
|
||
由于领域服务做了足够的封装，且保证了它与技术实现的隔离，应用服务的实现就变得简单了：
|
||
|
||
package settlement.application;
|
||
|
||
import settlement.domain.SettlementBillTemplateExporter;
|
||
import settlement.domain.OutputStreamProvider;
|
||
import settlement.domain.exceptions.SettlementBillFileFailedException;
|
||
|
||
public class SettlementBillAppService {
|
||
@Service
|
||
private SettlementBillTemplateExporter exporter;
|
||
|
||
public void exportByTemplate(OutputStreamProvider streamProvider, String templateName, String billNumber) {
|
||
try {
|
||
exporter.export(streamProvider, templateName, billNumber);
|
||
} catch (TemplateFileFailedException ex) {
|
||
throw new ApplicationException("Failed to export settlement bill file.", ex);
|
||
}
|
||
}
|
||
}
|
||
|
||
|
||
|
||
作为“北向网关”的控制器，本质上属于基础设施层的类，且它的职责是响应客户端发过来的 HTTP 请求，因此，它依赖于 Servlet 框架是合乎情理的。同时，它对应用服务的依赖也满足整洁架构的设计原则。基于新领域模型的控制器类 BillTemplateController 实现为：
|
||
|
||
package settlement.gateways.controllers;
|
||
|
||
import settlement.application.SettlementBillAppService;
|
||
import settlement.gateways.controllers.model.ExportBillReviewRequest;
|
||
import java.io.OutputStream;
|
||
import javax.servlet.http.HttpServletResponse;
|
||
|
||
@RestController
|
||
@RequestMapping("/bill-review")
|
||
public class BillTemplateController {
|
||
@Resource
|
||
private SettlementBillAppService settlementBillService;
|
||
|
||
@PostMapping("/export-template")
|
||
public void exportBillReviewByTemplate(HttpServletResponse response, @RequestBody ExportBillReviewRequest request) {
|
||
settlementBillService.exportByTemplate(response::getOutputStream, request.getTemplateName(), request.getBillNumber());
|
||
}
|
||
}
|
||
|
||
|
||
|
||
代码的层次结构
|
||
|
||
当我们进行领域分析建模和设计建模之后，获得的领域设计模型应在正确表达领域逻辑的同时，还要隔离具体的技术实现。这就需要在设计时把握领域驱动的设计要素，明确它们各自的职责与协作方式。既要避免不合理的贫血模型，又要注意划分清晰的层次架构，防止业务复杂度与技术复杂度的混淆。改进后的领域设计模型对应的代码层次结构为：
|
||
|
||
settlement
|
||
- application
|
||
- SettlementBillAppService
|
||
- domain
|
||
- SettlementBillTemplate
|
||
- InternalSettlementBillTemplate
|
||
- TransactionalSettlementBillTemplate
|
||
- TemplateVariable
|
||
- SettlementBill
|
||
- SettlementBillExporter
|
||
- OutputStreamProvider
|
||
- exceptions
|
||
- TemplateFileFailedException
|
||
- DownloadTemplateFileException
|
||
- OpenTemplateFileException
|
||
- repositories（persistence技术实现的抽象）
|
||
- SettlementBillTemplateRepository
|
||
- interfaces（技术实现层面的抽象）
|
||
- file
|
||
- WorkbookReader
|
||
- WorkbookWriter
|
||
- gateways（包含技术实现层面）
|
||
- persistence
|
||
- SettlementBillTemplateMapper
|
||
- file
|
||
- ExcelWorkbookReader
|
||
- ExcelWorkbookWriter
|
||
- controllers
|
||
- BillTemplateController
|
||
- model
|
||
- ExportBillReviewRequest
|
||
|
||
|
||
|
||
总结
|
||
|
||
通过对领域设计模型的逐步演化，我们改进了导出结算账单领域逻辑的代码结构与实现。之前建立的领域设计模型以及代码实现存在诸多问题，皆为领域驱动设计新手易犯的错误，包括：
|
||
|
||
|
||
未能在领域分析模型中正确地表达领域知识
|
||
贫血的领域模型
|
||
层次不清，对领域驱动设计的分层架构理解混乱
|
||
领域服务与应用服务概念混乱
|
||
业务逻辑与技术实现纠缠在一起
|
||
|
||
|
||
追本溯源，这些问题源于团队没有建立正确的领域设计模型。进一步回归问题的原点，在于团队没有为领域建立统一语言。回顾前面对模板导出业务的分析，每一个步骤都没有准确地表达业务逻辑，由此获得的领域对象怎么可能正确呢？又由于没有建立统一语言，导致类和方法的命名都没有很好地体现领域概念，甚至导致某些表达领域概念的类被错误地放在了基础设施层。在运用面向对象编程范式进行设计和实现时，对面向对象思想的理解偏差与知识缺乏也反映到了代码的实现上，尤其是对“贫血模型”的理解，对职责分配的认知，都会直接反映到代码层面上。
|
||
|
||
回到战略层面，团队成员显然没有真正理解分层架构各层的含义，为了分层而分层，这就可能随着功能的增加，渐渐无法守住分层架构中各层的边界，导致业务复杂度与技术复杂度之间的混合。若系统简单也就罢了，一旦业务复杂度的增加带来规模的扩大，不紧守架构层次的边界，就可能导致事先建立的分层架构名存实亡，代码变成大泥球，积重难返，最后回归太初的混沌世界。
|
||
|
||
|
||
|
||
|