光脚丫思考的专栏

搞数据的都知道，阿里发明了数据中台，然后“中台”这个概念就马上成为了国内大多数企业趋之若鹜的风口，真正实施后却发现中台与数据平台、数据湖等项目大差不差，又有好多机构开始忙着拆中台了，中台虽然还没到人见人烦的地步，但总体来讲已经不那么受待见了。我发现网上也有很多文章进行分析，但大多是长篇大论，表述也过于技术，今天我就用最通俗的话跟大家解释一下。中台的概念首先，先解释一下中台的概念首先，不论是数据中台，还是业务中台，都属于中台的一种。而中台的职责在于抽象共性形成通用服务能力。而数据中台就是抽象

领域模型的优势充分利用了面向对象设计的优势。无需受到数据库结构的限制。可以很轻易的替换掉数据访问层。领域模型的劣势很难将整个系统构想成一个抽象模型。需要引入新的复杂性来处理现有复杂性。主要障碍是对象和关系型数据库之间的不匹配。不过有O/R映射工具。

领域模型模式随着系统复杂性的提高，关注数据的劣势也逐渐显露出来，因此你需要开始同时关注与数据和行为。从长远来看，以数据为中心的方法并不能很好地适应规模的增加。领域驱动设计。领域模型模式力求让对象模型与系统的概念模型匹配起来，这样的对象模型就叫做领域模型。领域模型描述了系统中涉及的实体，捕获了实体之间的关系以及数据在其中的交换过程。一系列彼此相连的对象。领域模型中的实体将成为

领域模型模式中，执行数据库操作的代码叫做数据映射器。数据映射器模式是指使用一系列类将逻辑实体(以及其所有的关系)映射至数据表和记录(通常在关系型数据库)之上。领域模型的最重要难点：数据映射器的实现完全由手工完成。

通常领域模型中的类包含数据和行为，不过行为仅仅用来表示实体的逻辑，不包含加载数据相关的逻辑。一般会为每个实体创建一个仓储对象。将领域实体和持久化逻辑拆分开好处：可以很容易地为仓储提取接口，随后使用工厂模式将所有数据库代码封转到一个实现了该接口的对象中。这样，领域模型即可配合任意的数据访问层以及数据提供器。仓储工厂在内部可以读取实际的类型，并根据配置文件进行实例化，这样就使整个解决方案更

何时使用领域模型？业务逻辑的重用性需求就成为判断是否值得使用领域模型的一个关键参数。复杂性是选用领域模型模式的主要动力，复杂性应该按照现有需求来衡量，不过也应该考虑到日后可能出现的增强或修改需求。

缺点：容易导致出现很多小的类，使得命名空间变得混乱。优点：可以很容易的将一系列的活动组成一个更大的事务。

适合应用于那些业务逻辑非常简明直白，且最好不大可能改变的简单场景。简易度和复杂性很难衡量。对象能让代码变得优雅，不过优雅只是代码可以正常工作之后的锦上添花。数据访问通常被封装在另一些组件中，并不属于脚本的部分。

关注点在于用户通过表现层所能执行的操作，并为每个操作编写一个专门的方法。这个方法就叫做一个事务脚本。事务指一个需要执行的业务流程。脚本表示我们会逻辑上将一系列系统操作与每个用户操作关联。

扮演着活动记录类和物理数据库之间接口的角色。行数据网关将所有活动记录相关的数据代码封装了起来。行数据网关类仅应该包含数据库访问逻辑，而不应该包含领域逻辑。

领域模型中的类型总是不会提供显式执行数据库访问的方法。领域对象中不应该包含有关持久化的代码，因为将持久化和领域逻辑这两个职责放在一起会违反单一职责原则。领域类型总是需要持久化的，真正的问题是这部分代码应该放在何处，是在领域类型中呢？还是领域类型之外呢？

和活动记录的区别：领域模型是和数据库无关。主要参与者实体、辅助的实体。避免公共逻辑的重复。可定义一个基类，包含所有的公共逻辑，并作为领域模型对象的超类型。Microsoft Enterprise Library 4.0提供了一个很不错的验证组件。领域对象中不包含任何将其状态保存至存储介质的逻辑。

服务的定义：在非技术的上下文中，一个与业务相关的操作，应用程序中的每个客户都可以重复地执行，这些客户包括用户、程序中的其他服务以及业务逻辑中的其他部分等。OASIS的定义一种允许访问一个或多个功能的机制，访问要通过规定的接口，且严格一致地按照服务描述中给出的约束和策略。服务就是对某个类进行另一层的封装。服务通常被设计成一个无状态的组件，一般来说，无状态组件的可伸缩性更好，其

本演示介绍了MEF的生命周期管理，重点介绍了导出部件的三种创建策略，分别是：CreationPolicy.Any、CreationPolicy.Shared、CreationPolicy.NonShared。

本示例演示如何使用MEF提供的目录（Catalog）的扩展机制实现可过滤导出部件的自定义目录类。主要是通过继承ComposablePartCatalog基类，并实现接口INotifyComposablePartCatalogChanged来完成的。

没有服务层，则表现层直接调用到应用服务中，这就会造成一个大粒度的远程接口，从而导致过多的交互。

在Fowler看来，服务层用作表现层和业务逻辑层的边界。1、服务层的目的：服务层位于两个互相不通信的逻辑层之间，使两个层能够松散耦合并有没地彼此分离的同时，仍旧可以完美的彼此通信。感悟 2、组织系统的行为：服务层将业务逻辑层中所有的细节对表现层隐藏起来。业务逻辑层中唯一需要完全和数据库细节分离的部分就是领域模型。理论上服务层应该通过数据迁移对象与表现层交互。

服务层实际上不执行任何具体的工作，其功能在于组织各个业务对象、应用程序专有的服务、工作流以及其他任何出现在业务逻辑中的特殊组件。

服务层中的类应该暴漏契约。实现接口是个不错的选择。该接口可能用数据迁移对象来接收并返回数据，且选用粗粒度而不是细粒度的方法，以降低来回通信次数并提高吞吐量。为问题领域中的每个实体创建一个服务类，也可以考虑使用一个服务类。强烈建议为每个服务都暴漏一个接口。

服务层的优势除去两个层之间的耦合。降低表现层与业务层之间的通信流量。服务层的劣势简单系统的服务层或许有过度设计之嫌。Flower的第一条有关分布式对象设计的建议：不要使用分布式，除非它真正能够带来好处。

一套公用的应用程序编程接口。表现层和业务逻辑层都不应该包含业务逻辑。老板=表现层、经理=服务层服务层应该用在所有有一定复杂性的应用程序中。若有多个前端且应用逻辑比较复杂，那么最好将整个应用逻辑放在同一的位置，而不是为每个应用程序接口都重新写一遍。

设计关系型数据库的基本原则：将信息放在不同的数据表中，并使用外键来建立数据表之间的逻辑关系。如何在活动记录模型中映射外键关系呢？1、直接映射原始值，领域中则展开映射关系。Fowler建议活动记录模型尽可能地简单，也即尽可能的贴近数据库结构。2、某些框架支持外键映射模式，并能延迟加载即展开关系。外键映射模式：在引用对象中以属性的方式给出引用到的真实对象的引用即可。

活动记录是指封装了数据库表或视图的一行的对象，对象可以包含数据和行为。活动记录对象的结构应尽可能的接近于相关联的数据表结构。活动对象中通常会包含用来执行查找的查找方法、CURD操作、验证以及领域相关的计算和检查功能。实例方法操作于当前对象；静态方法操作与数据表的所有记录。何时使用活动记录？领域逻辑不是太复杂，且与数据模型之间不需要很复杂的映射关系。活动记录的优势

1、开放/封闭原则模块应该对扩展开放，对修改关闭。每个类型应该是固定的，不在未来有任何变化，更不要修改类型的源代码。即类型对修改关闭。每次发生变化时，要通过添加新代码来增强现有类的行为，而不是修改原有代码。可以使用如下两种方式：①用组合创建新的类型。②使用安全干净的继承体系。在类型继承中，应该仅仅添加新代码，不应该修改任何继承得到的上下文。2、里氏替换原则子类应

面向对象的理念擅长于将系统分解成组件来描述流程，也擅长于处理组件的关注点。不过对于那些横切的关注点，面向对象理念却不在行。横切关注点是指那些将会影响到系统中多个组件的关注点。面向方面编程AOP。AOP的主要目的是将横切关注点于核心关注点的实现拆分开。在AOP中，我们可以将某个横切关注点封装到一个新的组件中，该组件就叫做一个方面。方面就是一个可重用的组件，其中封装了项目中多个类型需要

用一段泛化的代码控制更加特定的外部组件的执行。若满足了里氏替换原则和开放/封闭原则，那么改变任何外部组件都不会影响高层次的方法。外部组件和高层次方法可以分开开发。依赖注入的三种实现方式1、通过被注入方法所在的类的构造函数。2、通过在被注入方法所在的类中定义一个方法或属性。3、让被注入方法所在的类实现一个接口，接口中提供了辅助组件的具体实现。

惯用法是一个硬式编码在编程语言或实现在框架/技术中的模式。设计模式关注的是面向对象的设计理念，惯用法关注于编程语言的技术。考虑在特定技术或平台的上下文重新评估设计中应用原则的方式，这个过程中叫做惯用设计。应该尽可能地使用类，除非类型所占的存储空间低于16字节或类型是不可变的。推荐在公开签名中使用IList或其派生接口，或者使用实现了IList接口的自定义类型。

在于交付的时候解决方案是否能正常工作并满足需求。模式就是其他人已经遇到过并加以分类的问题的解决方案。重构模式的时候需要判断是否能够更好地适应未来的变化，并对当前的解决方案有所改进。软件架构师大多是关于决定的。反模式是一种介绍如何从问题演化到不好的解决方案的模式。

最合适的设计模式通常在重构的过程中渐渐浮出水面。批注 首先需要明确问题的关键，并将其一般化。然后在应用到程序的上下文中，通常会涉及代码的重构。

面向对象设计的一个重要步骤是为问题领域找到一个干净灵活的抽象。此时应该考虑的是事情而不是流程，应该关注的是什么，而不是如何。找到合适对象的做法：标记出所有用例中的所有名词和动词。1、尽量降低耦合将接口和实现分离开来，将会受益良多。基于接口，而不是实现编程。2、尽量保证代码重用白盒重用、黑盒重用。继承、组合、聚合。对象组合更加安全，且易于维护和测试，只是组合无法实现多

有助于实现软件的高内聚和低耦合。分离关注点的核心在于将系统拆分成各不相同且最好没有重叠的功能。尽可能保证模块之间没有功能上的重复。分离关注点是通过模块化代码以及大量的运用信息隐藏来实现的。模块的实现细节并不会被其他模块知晓或访问。信息隐藏也叫做封装。在面向对象的程序设计中，使用类来分离关注点。

耦合度用来度量两个软件模块之间的依赖程度。耦合度越低说明软件设计的越好。模块之间肯定需要进行通信，但依赖于一系列设计良好且不易改变的接口。

普遍认同的2种软件模式：设计模式和架构模式。重构模式模式的定义：每个模式都描述了一个问题，这个问题在我们的环境中一遍一遍出现。且模式还给出了这个问题的核心解决方案，这个方案可以被一次次地重用，而无需每次都从头开始。

若想设计出好的软件，普通的设计原则就够了，但时至今日，重复发明轮子绝对谈不上是什么好事。尽量保证简单，但不要再继续简单下去了。不要重复自己。一次且尽一次。你不会用到它。

总的来说，表模块业务组件中的成员一般应该是实例成员。理由如下：1、可以根据某个查询的结果来初始化类型。2、可以实现查询对象模式。表模块并没有提供区分各个子对象的概念。表模块类在内部存放的是一个弱类型数据行的集合，而不是强类型的对象集合。业务组件关注点在于应用程序的数据，而不是用户的操作。强类型DataSet、表适配器。表数据网关模式使用表适配器作为表模块类。

若某个方法不需要与类中的其他成员交互，那么使用静态方法。一般而言，若某个方法或属性和类是一个整体，那么就应该是静态的。若某个方法或属性和特定的实例紧密相关，则不应该是静态的。FxCop是微软公司的一个免费静态代码分析工具。为一个方法添加过多的参数显然并不友好。

事务脚本有造成代码重复的潜质，最终程序变成了一团混乱的子程序组合。通心粉代码。重构可以在很大程度上缓解事务脚本天生的劣势，但重构也有其范围。软件的回归测试。真正的敌人是重复，而不仅仅是代码重复。对脚本进行分组。

业务对象不过是某个领域实体(即封装了数据和行为的类)的实现。业务对象包含了数据和行为，是可以参与到领域逻辑中的完整对象。数据迁移对象更像是一种值对象，即一系列数据的容器而没有相关的行为。领域实体类型可能会与多个对应的数据迁移对象。数据迁移对象仅仅是所需部分数据的投影而已。使用业务对象？还是数据迁移对象？整洁干净？还是减少类的数量？

系统设计的难点通常在于为业务创建合适的软件模型。对象模型仅仅是一系列的对象，并不包含模型在设计和实现上的约束。领域模型是一个用来实现一系列需求的对象模型。

抽象地说，业务逻辑层是软件中专门处理业务相关任务性能的部分。业务层是所有分层系统的核心，包含了系统的核心逻辑。通常也叫作业务逻辑层。