在领域驱动设计过程中,正确地进行领域建模是至为关键的环节。如果我们没有能够从业务需求中发现正确的领域概念,就可能导致职责的分配不合理,业务流程不清晰,出现没有任何领域行为的贫血对象,甚至做出错误的设计决策。

错误的设计

在一个航延结算系统中,业务需求要求导入一个结算账单模板的 Excel 文档,然后通过账单号查询该模板需要填充的变量值,生成并导出最终需要的结算账单。结算账单有多种,如内部结算账单等。不同账单的模板并不相同,需要填充的变量值也不相同。

团队对此进行了领域建模,识别了表达领域概念的领域模型对象,包括:

  • InternalSettlementBill
  • TemplateReplacement
  • BaseBillReviewExportTemplate
  • InternalSettlementBillService
  • BillReviewService

在这些对象中,InternalSettlementBill 被定义为实体类,TemplateReplacement 被定义为值对象。由于存在多种结算账单,实现时考虑了代码的可扩展与重用,在设计模型中引入了模板方法模式改进领域模型,即引入的 BaseBillReviewExportTemplate。注意,该抽象类命名中包含的 Template 并非结算账单模板,而是为了体现它运用了模板方法模式。同时,还定义了领域服务 InternalSettlementBillService 和 BillReviewService。它们之间的关系如下所示:

【DDD】学习笔记-领域设计模型的价值案例-LMLPHP

实现代码为:

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 工作薄。

根据该业务流程,可以识别出如下职责:

  • 导入结算账单模板
  • 获取结算账单模板变量
  • 基于模板变量填充结算账单模板,生成结算账单
  • 导出结算账单

通过分析这些职责,尤其关注职责中描述的领域概念,并识别职责的履行者,可以获得如下所示的领域模型:

【DDD】学习笔记-领域设计模型的价值案例-LMLPHP

对比前后两个领域模型,我引入了 SettlementBillTemplate 对象,由它代表结算账单模板。这里要特别注意区分结算账单(SettlementBill)结算账单模板(SettlementBillTemplate)两个概念。模板规定了结算账单填充数据的内容和格式,不同的结算账单会有不同的模板。一旦填充了模板变量值后,就会形成结算账单。虽然从领域概念上讲,结算账单有多种类别,如内部结算账单、交易结算账单等。但这个区别主要体现在模板上,因为它决定了结算账单要填充的值,至于结算账单本身是没有任何区别的。因此,在导出结算账单这个业务场景中,不同账单的区别就体现在模板和模板变量值上。模板和模板变量放在同一个聚合中。可以为模板定义如下的继承体系,继承体系中的每个子类为一个独立的聚合:

【DDD】学习笔记-领域设计模型的价值案例-LMLPHP

避免贫血模型

一旦理清了需求,就可以获得正确的领域分析模型与设计模型。每个领域模型对象都体现了领域知识,也可以让我们根据它们所拥有的数据合理分配职责。在前面给出的领域设计模型中,一个模板可以包含多个模板变量,模板变量的值就来自这个作为主体的模板实体对象。每个模板对象自身了解自己的变量是哪些,该如何组装这些模板变量。根据“信息专家模式”,这个组装模板变量的功能就该分配给模板实体,而非之前模型中的 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

总结

通过对领域设计模型的逐步演化,我们改进了导出结算账单领域逻辑的代码结构与实现。之前建立的领域设计模型以及代码实现存在诸多问题,皆为领域驱动设计新手易犯的错误,包括:

  • 未能在领域分析模型中正确地表达领域知识
  • 贫血的领域模型
  • 层次不清,对领域驱动设计的分层架构理解混乱
  • 领域服务与应用服务概念混乱
  • 业务逻辑与技术实现纠缠在一起

追本溯源,这些问题源于团队没有建立正确的领域设计模型。进一步回归问题的原点,在于团队没有为领域建立统一语言。回顾前面对模板导出业务的分析,每一个步骤都没有准确地表达业务逻辑,由此获得的领域对象怎么可能正确呢?又由于没有建立统一语言,导致类和方法的命名都没有很好地体现领域概念,甚至导致某些表达领域概念的类被错误地放在了基础设施层。在运用面向对象编程范式进行设计和实现时,对面向对象思想的理解偏差与知识缺乏也反映到了代码的实现上,尤其是对“贫血模型”的理解,对职责分配的认知,都会直接反映到代码层面上。

回到战略层面,团队成员显然没有真正理解分层架构各层的含义,为了分层而分层,这就可能随着功能的增加,渐渐无法守住分层架构中各层的边界,导致业务复杂度与技术复杂度之间的混合。若系统简单也就罢了,一旦业务复杂度的增加带来规模的扩大,不紧守架构层次的边界,就可能导致事先建立的分层架构名存实亡,代码变成大泥球,积重难返,最后回归太初的混沌世界。

02-20 08:36