为什么我们需要正确地领域建模-阿里云开发者社区

广而告知：我在GitChat的领域驱动战略设计实践达人课已经发布，目前正在进入预售期。点击文末“阅读原文”即可查看与订阅，也可以通过微信扫描下方的专属海报进行订阅。由于本文内容太长，你也可以移步至我的博客http://zhangyi.xyz获得更加阅读体验。记住我的博客，张逸的拼音全名，域名为xyz。

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

最初的实现

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

团队确实进行了领域建模，发现了如下的几个领域概念以及对应的服务和资源库对象：

InternalSettlementBill
InternalSettlementBillRepository
TemplateReplacement
BaseBillReviewExportTemplate
InternalSettlementBillService
BillReviewService

为了方便大家对这个设计有直观认识，我先贴出这些关键类型的实现代码：

package settlement.domain;
import lombok.Data;
@Data
public class InternalSettlementBill {
    private String billNumber;
    private String newAndOldBillNumber;
    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 interface InternalSettlementBillRepository {
    InternalSettlementBill queryByBillNumber(String billNumber);
}
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.getNewAndOldBillNumber()));
        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 settlement.web.controllers;
import settlement.domain.*;
import settlement.web.model.ExportBillReviewRequest;
import org.springframework.web.bind.annotation.*;
import javax.annotation.Resource;
import javax.servlet.http.HttpServletResponse;
@RestController
@RequestMapping("/bill-review")
public class BillReviewController {
    @Resource
    private BillReviewService billReviewService;
    @PostMapping("/export-template")
    public void exportBillReviewByTemplate(HttpServletResponse response, @RequestBody ExportBillReviewRequest request) {
        billReviewService.exportBillReviewByTemplate(response, request.getBillNumber(), request.getTemplateName());
    }
}

在这些类中，领域层的InternalSettlementBill表达的是“内部结算账单”领域概念，显然，如代码所示，这个对象是一个典型的贫血对象。BaseBillReviewExportTemplate类是一个抽象类，InternalSettlementBillService是继承它的子类。团队开发人员运用了模板方法模式，BaseBillReviewExportTemplate是获取各种结算账单的TemplateReplacement的一个抽象，因为开发人员发现这个过程是通用的：

通过billNumber查询结算账单
根据结算账单的值组装导出账单需要的模板替换对象

提炼领域知识

BaseBillReviewExportTemplate是一个领域服务，但它其实有一个很糟糕的命名，让人无法看懂它到底承担了什么职责？从命名看，它蕴含了多个概念：bill、review、export、template。究竟要做什么？是账单评阅的导出模板？还是导出账单评阅的模板？它代表了模板的名词概念，还是代表导出的领域行为？真是让人丈二和尚摸不着头脑。其实，阅读其代码实现，发现这个类要做的不过就是获得结算账单的所谓“模板替换（TemplateReplacement）”对象罢了？

TemplateReplacement表达的是什么概念呢？通过和团队成员沟通需求，结合代码我梳理出要实现的业务逻辑：

用户首先导入一个结算账单模板的Excel工作薄；
Excel工作薄模板中对应的单元格中定义了一些变量值；系统需要从数据库中读取结算账单的信息，然后基于结算账单信息中的值去替换定义在模板中的这些变量；
导出替换了变量值的Excel工作薄。

显然，替换模板中的变量值是我们期望完成的行为，其本质其实应该是一个模板变量：TemplateVariable。这个对象属于领域层的领域概念，不应该被定义在基础设施层。

如此，BaseBillReviewExportTemplate这个服务的命名就真可以说是名实不副了，不如更名为BaseBillTemplateVariablesComposer。但仔细看它的实现，我发现它不过就是通过一个Repository获得结算账单，再用结算账单中的对应值去组装模板变量。这个组装模板变量的行为放在这个服务中合适吗？遵循“信息专家模式”，InternalSettlementBill自身就具备了组装模板变量的信息，它才是承担组装职责的最佳专家啊！于是，我们可以转移职责：

package settlement.domain;
@Data
public class InternalSettlementBill {
    private String billNumber;
    private String newAndOldBillNumber;
    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.newAndOldBillNumber()),
            new TemplateVariable(1, 0, this.flightIdentity()),
            new TemplateVariable(1, 2, this.flightRoute())
        );
    }
}

由于不同的结算模板都提供了不同的模板变量，我们就可以为其定义一个抽象的结算模板类型：

package settlement.domain;
public interface SettlementBill {
    List<TemplateVariable> composeVariables();
}
package settlement.domain;
public class InternalSettlementBill implements SettlementBill {}

在转移了组装模板变量的职责后，我已经看不出BaseBillTemplateVariablesComposer这个服务还有什么存在必要了！是的，它还承担了调用Repository去获得结算账单的职责，但在转移了组装模板变量的职责后，这个服务已经被弱化为只剩下查询职责了。这个查询结算账单的职责不是Repository提供的么？再对这个查询功能做一次封装有何意义？所以，在InternalSettlementBill摆脱“贫血对象”的身份后，看起来很酷的模板方法模式就变得没有任何价值了！

保持清晰的领域服务

再来看服务BillReviewService服务。从实现内容看，它才是真正负责导出结算账单的服务。这个服务的类名既含糊，实现代码又混乱，看起来它根本就不是一个纯粹的业务服务，因为它将业务逻辑与技术实现搅在了一起：既有Excel工作薄的获取，又有通过poi框架实现对单元格数据的填充，还有文件的下载，同时还通过结算账单获得了需要填充的模板变量值。

之所以会出现如此混乱的局面，除了没有有效地将技术实现与业务逻辑通过抽象去隔离之外，最关键的还是没有正确地建立领域模型。实际上，这里的结算账单模板不正是我们要操作的领域对象吗？实际上，我们要完成的业务功能是填充以及导出结算账单模板，而不是填充工作薄的单元格，自然也不是下载工作薄文件。所谓的“工作薄”概念，其实是实现层面的细节。

为保障设计的纯粹性，我们理当将结算账单模板定义为一个POJO类型的领域实体对象。即使需要将其导出为Excel工作薄，我们也可以令其持有数据，然后再将数据写入到工作薄。但是，由于结算账单模板的部分内容是通过模板文件直接导入的，除了需要替换的模板变量值之外，其余内容无需重新写入。如果硬要将其定义为纯粹的领域对象，就需要记录账单所有值在工作薄中的坐标，以便于在生成模板文件时正确地填充值；然而，这个模板的部分值在工作薄文件中已经存在了，再做一次无谓的填充就显得多余了。故而，我们需要做一个设计妥协，直接将poi框架的HSSFWorkbook作为结算账单模板对象内部持有的属性。让领域层依赖poi框架使得我们的领域模型不再纯粹，但为了技术实现的便利性，偶尔退让一步，也未为不可，只要我们能守住底线：保持系统架构的清晰层次。

一旦将工作薄对象赋予结算账单模板对象，则模板自身就不再有多种结算账单类别，因为它们的区别在于workbook。因此，我们没有必要为各种结算账单定义对应的模板对象，只需一个SettlementBillTemplate即可：

package settlement.domain;
import org.apache.poi.hsf.usermodel.*;
public class SettlementBillTemplate {
    private HSSFWorkbook workbook;
    private int sheetIndex;
    private String replacePattern;
    public SettlementBillTemplate(HSSFWorkbook workbook) {
        this(workbook, 0, "@replace");
    }
    public SettlementBillTemplate(HSSFWorkbook workbook, int sheetIndex, String replacePattern) {
        this.workbook = workbook;
        this.sheetIndex = sheetIndex;
        this.replacePattern = replacePattern;
    }
}

既然SettlementBillTemplate已经拥有了工作薄对象，为何不将填充模板变量值的功能赋予它呢？

public class SettlementBillTemplate {
    public void fillWith(SettlementBill bill) {
        HSSFSheet sheet = hssfWorkbook.getSheetAt(sheetIndex);
        bill.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);
            }
        });
    }
}

现在，组装模板以及模板变量的工作已经完成，剩下的就是导出模板了。那么，谁该拥有导出模板的能力呢？虽然要导出的数据是SettlementBillTemplate拥有的，但它并不具备读取与下载工作薄文件的能力，既然如此，就只能将其放到领域服务。你看，我在分配表达领域逻辑的职责时，是将领域服务排在最后的顺序。

在此之前，我们还需要分离业务逻辑与技术实现。什么是业务逻辑？组装模板变量，组装模板以及导出模板都是业务逻辑，而读/写工作薄文件则是技术实现。既然如此，工作薄文件的读写职责就应该分配给基础设施层，然后在interfaces模块中定义它们的抽象接口。注：改进后的代码采用的代码结构皆以我的推荐为准。例如下面的接口定义是放在interfaces/file包中，实现放在gateways/file包中：

package settlement.interfaces.file;
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
public interface WorkbookReader {
    HSSFWorkbook readFrom(String templateName);
}
public interface WorkbookWriter {
    void writeTo(HSSFWorkbook workbook, String targetPath);
}
package settlement.gateways.file;
import settlement.interfaces.file.WorkbookReader;
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
public class ExcelWorkbookReader implements WorkbookReader {}
package settlement.gateways.file;
import settlement.interfaces.file.WorkbookWriter;
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
public class ExcelWorkbookWriter implements WorkbookWriter {}

解决资源库多态的问题

还有一个问题没有解决，就是不同的结算账单是通过不同的Repository获得的。虽然模板已经没有类型的区别了，但用组装模板的模板变量值确实是不相同的。我们需要根据传入的templateName决定获得什么样的结算账单对象。但是，我们之前已经为InternalSettlementBill定义了对应的Repository，且它被定义为一个接口。是否可以将这个接口作为服务的属性，交给依赖注入去注入实现呢？例如：

public class SettlementBillTemplateExporter {
    @Resource
    private InternalSettlementBillRepository repository;
}

这是不对的。因为采用这样的定义，就意味着SettlementBillTemplateExporter服务只能查询InternalSettlementBill。要解决这个问题，似乎可以为资源库查询所有结算账单的行为定义一个统一接口，如SettlementBillFinder接口。然而，这一改进还是不能解决问题，因为决定实例化哪个Repository，是由调用者传递的templateName决定的。

在进行领域驱动设计时，为了隔离业务逻辑与技术实现，一般建议对技术实现尽可能做抽象，例如定义抽象的Repository接口，然后再利用依赖注入（Dependency Injection）完成对具体实现的注入。当我们使用框架来完成依赖注入时，就要求领域层的领域对象包括Repository、Service等对象都将由IoC框架来管理生命周期。这些IoC框架在带来依赖管理的便利时，也给我们的设计施加了一些约束。

一种解决办法是为资源库引入静态工厂：

package settlement.repositories;
public interface SettlementBillFinder {
    SettlementBill settlementBillBy(String billNumber);
}
package settlement.repositories;
public interface InternalSettlementBillRepository extends SettlementBillFinder {
    // other methods;
}
package settlement.domain;
import settlement.repositories.SettlementBillFinder;
import settlement.gateways.persistence.InternalSettlementBillMapper;
public class SettlementBillFinderFactory {
    public static SettlementBillFinder create(String templateName) {
        switch (templateName.toLowerCase()) {
            case "internal": 
                return new InternalSettlementBillMapper();
            // 其余分支略
        }
    }
}

然而，这样的设计是有问题的，因为它破坏了各层的职责。如上所示的SettlementBillFinderFactory是一个静态工厂，它需要创建具体的资源库对象，就意味着它依赖了基础设施层的类，即放在gateways/persistence中的InternalSettlementBillMapper类，而工厂自身却属于领域层。倘若采用这种做法的话，前面运用的依赖注入方法就变得没有意义了。在领域驱动设计的实现时，我们确实需要时时刻刻保持谨慎，防守住因为某种实现原因导致对整洁架构的破坏。

要做到这一点，可以考虑使用工厂方法模式，为工厂再定义一个抽象，转而将实现放到基础设施层。例如：

package settlement.domain;
public interface SettlementBillFinderFactory {
    SettlementBillFinder create();
}

可惜，这样一个多态的工厂让我们又走回了老路，因为需要调用者根据templateName决定使用哪一个具体工厂！这与通过templateName确定选择使用哪一个Repository又有何区别呢？反而引入了不必要的间接。

如果使用Spring来管理依赖注入，有一种做法是在服务中定义一个HashMap<String, String>，其中key值对应模板名，value值对应SettlementBillFinder实现子类的类名，然后在配置文件中配置这些映射信息。当服务传入一个templateName时，在这个hashmap中搜索获得的子类类型，然后利用反射来创建这些类。这一方法看起来保证了可扩展性，但实在太繁琐，太复杂，且反射的使用也在一定程度影响了性能。

有两种更简单的办法：

让Repository的实现子类自行判断：如果我们将结算账单视为一个领域概念，就应该为其只抽象一个SettlementBillRepository。即无需为每种结算账单提供专有的资源库抽象。在定义Repository的查询方法时，将templateName与billNumber都视为查询的条件，然后在实现类中根据templateName去查询不同的表，获得不同的结算账单领域对象。这个方法胜在简单，但较为死板不易扩展。
采用惯例优于配置（CoC）：依然将templateName作为服务方法的参数，也依旧提供一个SettlementBillRepository抽象，但在基础设施层为每个结算账单提供一个实现，且实现类遵循命名规则，即以{templateName}名字（单词首字母大写）为前缀，后缀统一为SettlementBillRepository，这样就可以基于规则组装类的类型名，再通过反射创建资源库对象。这一方法胜在能扩展，但依旧引入了反射。

这里我选择使用最简单的第一种方案，于是导出服务就变为：

package settlement.domain;
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) {
        SettlementBill bill = repository.settlementBillBy(templateName, billNumber);
        SettlementBillTemplate template = new SettlementBillTemplate(reader.readFrom(templateName));
        template.fillWith(bill);
        writer.writeTo(response, template, templateName);
    }
}

尽可能保证领域层的整洁

事情还未结束，因为在领域服务的方法中出现了“恼人”的HttpServletReponse，它属于servlet包的核心对象。在干净的领域层中，怎么能容忍它的出现呢？（当然poi框架的依赖算是例外，前面已经分析过。）仔细分析，我发现在导出逻辑的实现中，其实仅仅用到了HttpServletResponse对象的getOutputStream()方法，返回的OutputStream对象则是JDK中java.io库中的一个类。既然如此，我们可以在领域层为这一需求提供一个抽象，例如定义接口OutputStreamProvider：

package settlement.domain;
import java.io.OutputStream;
public interface OutputStreamProvider {
    OutputStream getOutputStream();
}

现在的领域服务就可以使用在领域层中自定义的OutputStreamProvider抽象。此外，还得加上一些异常处理：

package settlement.domain;
import settlement.domain.exceptions.*;
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 {
            SettlementBill bill = repository.settlementBillBy(templateName, billNumber);
            SettlementBillTemplate template = new SettlementBillTemplate(reader.readFrom(templateName));
            template.fillWith(bill);
            writer.writeTo(streamProvider, template, templateName);
        } catch (DownloadTemplateFileException | OpenTemplateFileException ex) {
            throw new TemplateFileFailedException(ex.getMessage(), ex);
        }
    }
}

应用服务的定义就变得简单了：

package settlement.application;
import settlement.domain.SettlementBillTemplateExporter;
import settlement.domain.OutputStreamProvider;
import settlement.domain.exceptions.TemplateFileFailedException;
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);
        }
    }
}

对应的，控制器的实现修改为：

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) {
        exportService.exportByTemplate(response::getOutputStream, request.getTemplateName(), request.getBillNumber());
    }
}

代码的层次结构

如上代码的层次结构为：

settlement
    - application
        - SettlementBillAppService
    - domain
        - SettlementBill
        - TemplateVariable
        - InternalSettlementBill
        - SettlementBillTemplate
        - SettlementBillTemplateExporter
        - OutputStreamProvider
        - exceptions
            - TemplateFileFailedException 
            - DownloadTemplateFileException
            - OpenTemplateFileException
    - repositories（persistence技术实现的抽象）
        - SettlementBillRepository
    - interfaces（技术实现层面的抽象）
        - file
            - WorkbookReader
            - WorkbookWriter
    - gateways（包含技术实现层面）
        - persistence
            - SettlementBillMapper
        - file
            - ExcelWorkbookReader
            - ExcelWorkbookWriter
        - controllers
            - BillTemplateController 
            - model
                - ExportBillReviewRequest

总结

通过以上对代码的逐步演化，我们就此可以发现原来代码的诸多问题。这些问题往往是许多领域驱动设计新手容易犯的错误，包括：

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

回归这些问题的原点，其实还是在于团队没有正确地进行领域建模。如果还要继续深究，则在于团队没有为领域建立统一语言。我们看前面对模板导出业务的分析，每一个步骤都没有正确表达业务逻辑，因而获得的领域对象也是不正确的。又由于没有建立统一语言，导致对类和方法的命名都不能很好地体现领域概念，甚至导致某些表达领域概念的类被错误地放在了基础设施层。当我们在运用面向对象编程范式来实现领域驱动设计时，对OO思想的理解偏差与知识缺乏也反映到了代码的实现上，尤其是对“贫血模型”的理解，对职责分配的认知，都会直接反映到代码层面上。

最后，如果团队成员没有清晰地理解分层架构各层的含义，以及为何要引入分层架构，就无法守住分层架构各层的边界，最后就会导致业务复杂度与技术复杂度的混搭。若系统简单还好说，一旦系统的业务复杂度增加带来系统规模的扩大，不紧守架构层次的边界，就可能导致我们事先建立的分层架构名存实亡，代码变成大泥球，重新回归到太初的混沌世界。

为什么我们需要正确地领域建模

最初的实现

提炼领域知识

保持清晰的领域服务

解决资源库多态的问题

尽可能保证领域层的整洁

代码的层次结构

总结

热门文章

最新文章

相关电子书

相关实验场景