在企业内部网站的建设过程中，网站后端最初采用传统的表模式的开发方式。这种方式极易导致站点的核心业务逻辑和业务规则分布在架构的各个层和对象中，这使得系统业务逻辑的复用性不高。为了解决这个问题，作者在后期的开发过程中引入了领域驱动设计的开发方式，把系统的业务逻辑独立建模、充分地复用，并基于这些模型打造易于扩展的开发框架，提高了整个团队开发业务逻辑的效率，最终网站如期上线，稳定运行至今。
目录
1 软件开发的三种模式
1.1 事务脚本
1.2 表模式
1.3 领域驱动设计模式
数字化是每个IT企业系统建设必不可少的一个环节，而企业内部网站往往也是数字化的重要标志和组成部分。企业内部站点建设项目就是在这种场景下诞生的，主要就是为顺利开展研发部门的日常工作，提供所需的管理各项流程制度的功能。
在项目的开始阶段，作者在研发方式上选择了常见的表模式来开发网站后端，在架构上选用了传统的多层架构来组织代码。这种技术选型和搭配常用于开发业务逻辑比较简单的小型项目，整个开发的过程都聚焦在具体的数据库设计和面向流程的开发上，对于团队成员来说简单易于上手。
不过，当网站的功能逐渐增多以后，系统的复杂度迅速攀升，采用这种搭配使得系统的业务逻辑得不到聚焦，最终它们零散地分布在架构的各个层和对象中，业务逻辑的复用性很差。
为了解决这个问题，作者引入了领域驱动设计的开发方式。这种开发方式聚焦于多变的业务逻辑，把它们作为系统开发的核心模型管理起来，这样就使得系统的业务逻辑得到了充分的复用，整个团队开发的效率就得到了显著的提高。
1 软件开发的三种模式
在软件开发中，根据研发过程的不同，一般把开发流程分为事务脚本、表模式和领域驱动设计三种模式。
1.1 事务脚本
1) 模式介绍
时至今日，虽然主流编程语言都是面向对象语言，但是很多团队都是采用面向过程的开发模式，代码中使用的对象并没有实际的意义，纯粹只是代码脚本的载体。
事务脚本(Transaction Script) 就是这样一种简单的开发模式，它完全采用的是面向过程的做法，直接将用户在表现层上所做的操作翻译成代码脚本(比如SQL语句、批处理语句等) 执行的模式。
2) 实现方式
通常，实现事务脚本模式不会进行对象设计，也不会对涉及的组件进行分层，所有从表现层到底层的操作全部放到一起。
典型的例子就比如展示图书列表的页面，开发的时候通常就是在界面上放置一个列表控件，然后该控件直接绑定从数据库中获取图书的SQL语句进行数据填充。增加和修改图书的时候也是类似，直接提供SQL语句操作数据库。
当然，为了使整个程序的结构更加清晰，在使用事务脚本模式时，很多团队也会进行简单的分层，这就是基本的多层架构的由来，也就是把应用分为如图1所示的三层。
在分层架构下，应用把整个业务流程分割并组织在不同的层级中，与用户直接交互的组件放在表现层中，用户在表现层的操作会被翻译成系统的输入数据模型并进入业务逻辑层，业务逻辑层再调用底层的数据访问层的脚本操作数据库、文件系统等数据源，完成业务逻辑。
在这个过程中，系统设计的重点依然是面向过程的，各个层和对象只是过程的载体，具体叫什么其实并没有什么太大的区别。
3) 应用场景
事务脚本是一种常用的开发模式，针对那些交互逻辑简单，业务模式几乎不会改变和发展的简单场景，比如常见的“增删改查型”应用，整个开发过程的效率会非常高。
1.2 表模式
1) 模式介绍
在研发过程中，数据库作为最重要的数据载体，在任何一个项目的开发过程中几乎是必然会出现的。在事务脚本中，与数据库交互基本都是通过在代码中直接使用 SQL 语句来完成的。
在常见的编程语言中，SQL语句都是作为字符串存在的，这就带来一个问题，由于字符串的内容不参与编译，所以如果SQL语句存在语法问题，那就只能到了应用运行时产生错误才会被发现，编译时发现不了，这有时会带来潜在的发布风险。
为了优化操作数据库的体验，提高代码编写的效率，在数据访问层，经过工程师们不断地尝试和努力，就出现了一种全新的数据交互方式，这就是通过编程语言中的实体对象来操作数据库中的数据。
2) 实现方式
以表模式为例，从具体实践上来说，它们是在事务脚本的基础上，把脚本操作变成了对象的操作。这个过程一般是通过特定的框架来完成的，这种框架一般被称为“对象关系映射(Object Relational Mapping，以下简称ORM) ”。ORM框架把关系数据库中的结构映射成语言中的实体对象，当调用实体的方法的时候，ORM框架就会将对象操作翻译成SQL语句，然后作用于数据库，如图2所示。
3) 应用场景
表模式优化了数据库访问的体验，但是并不涉及任何业务逻辑的处理，所以表模式和事务脚本一样，都非常适合那些业务逻辑简单的场景，对于较为复杂的应用场景则不太合适。
1.3 领域驱动设计模式
1) 模式介绍
事务脚本和表模式两种开发模式，主要采用的是面向过程的编程方法，而且在应用开发的过程中，需求分析和系统设计大都是分离的，这样就把应用开发前期的工作割裂开来，这也就导致了需求分析的结果与系统设计的代码不能完全匹配，以至于软件上线后，客户才发现许多功能不是自己想要的。不同于这两种模式，领域驱动设计(Domain Driven Design，以下简称DDD) 开发模式是纯粹的面向对象的设计过程，它以业务领域为核心，分析领域中的问题，通过设计和建立对应的“领域模型(对象) ”来有效的解决领域中的核心问题。
2) 实现方式
DDD是一种设计思路，为了实现聚焦业务逻辑，构建领域模型的目的，具体实施时一般分为战略设计和战术设计两个阶段。
战略设计阶段主要完成的工作是识别应用的领域，将领域细化得到子域，为每个子域设计限界上下文，并在这个过程中，通过与业务专家的充分讨论，得到描述业务的统一语言。战术设计阶段完的工作是根据限界上下文和统一语言，设计领域层中的领域模型对象，具体包括实体、值对象、领域事件、仓储、聚合和领域服务等(具体概念和细节可以参见文献) 。
DDD的具体实现也存在多种形式，本次网站的实践采用的就是经典的DDD的分层架构，整体架构图如图3所示。
表现层与以往的架构相同，主要是与用户交互的界面元素。
应用服务层是薄薄的一层，主要是把用户的输入转换成系统需要的数据模型和把系统生成的数据模型转化成表现层需要的对象模型，需要注意的是应用服务层主要完成转换和交接工作，调用基础设施完成一些诸如持久化的工作，千万不能实现任何的业务逻辑。
领域层是整个系统的核心层，它包含所有的领域模型。这些领域模型承载和实现了所有的业务逻辑和业务规则，所有的其他层都依赖于领域层，但是领域层不会依赖于任何其他层。基础设施层完成了的一些辅助的功能，比如一些第三方类库、具体的持久化实现如ORM等。
3) 应用场景
DDD开发模式特别适用于那些业务场景比较复杂、业务逻辑变化比较频繁、系统复杂度比较高的场景，典型的就比如中台系统的搭建、微服务的开发。
