基于抽象的分层结构

前言：现有已知的分层结构基本上是基于技术结构的，无论是SpringSide（早的还有AppFuse）还是DDD提出的分层结构，都是基于职责角色划分的。然而对于复杂的企业应用系统来说，仅仅以该纬度来划分，是无法完成逻辑的分解的。我们还需要基于抽象的分层纬度。

基于抽象的分层结构
众所周知：抽象是有排列的。进一步，在企业应用中，抽象的排列也是分层的；与此同时，抽象还是分模块的，定义良好的交互接口，保持抽象间交互的稳定是及其重要的。

抽象层次的划分是以业务概念划分为依据的，以保险系统为例，可以把抽象层次分为三层：保险其自身核心业务概念——核心抽象层，又受国家监管规则——国家抽象层，以及公司自身规则——公司抽象层。

如果说对于抽象的层次划分是纵向分类的话，那么模块划分就是横向分类。模块划分是较为常见的，不再举例。

对于抽象分层的，需要进一步的说明。如下为一个三层抽象的说明。白色为核心抽象层，水绿色为扩展抽象层，天蓝色为特定抽象层。

 

对于抽象的分层，是符合人的思维逻辑的一种思考问题的方式，由简单到复杂。注意到白色为代表的核心抽象其覆盖面积是最小的，其边界也是最小。然后是扩展抽象，再然后是特定抽象。对抽象分层的第二个好处是：可以迭代地螺旋前进。

先看看核心抽象层：核心抽象层必须足够精巧而且稳定，因为他们是系统的最基本和最简单的结构！同时核心抽象层是可以运行的！他们的抽象和默认实现在全系统的地位——类似于数学系统的中的0和1！而具有复杂变化的扩展层和特定层就类似于数学中的2和3，然而，我们都知道，在数学中，0和1才是最重要的，没有0和1，数学系统是无法构建的。

对于抽象层次而言，面临的问题是如何保护抽象层次的边界，确保上层抽象的变更不会引起下次抽象的具体变更。这就要求下层抽象在扩展实现时委派逻辑到扩展抽象层中新的接口和抽象。这样即保证了核心抽象的基本语义，由保护了核心抽象的边界。

系统必须支持核心抽象层为下层抽象留下扩展的空间，基本的手段是通过暴露Factory，将扩展实现注入到核心抽象层次中；除了扩展，系统还需要支持替换（override），也是要暴露核心层的Factory，将替换实现注入到系统中；现在很多基于类似Spring的系统，可以借助Spring的Bean Override机制完成；

这样的抽象层次由于本身是完备和有边界的，他们可以被独立地维护。

在全系统下的核心抽象层是0和1，然而在考虑扩展抽象层时，该层就成为其特定抽象层的0和1，我们需要像构建核心抽象层一样来构建该层，以保持本身的完备性，边界以及扩展性。

如此反复迭代，随着系统外围的边界不断扩大，全系统所提供功能也越来越多，扩展点也就越来越多，系统支持的动态特性也越来越多！

查看本文来源