引言
架构的抽象思维这个概念很难解释，希望不会翻车，因为太抽象了.....，只能尽所能了。（为了方便说明文章中的架构均指IT架构）
抽象的定义
抽象是从众多的事物中抽取出共同的、本质性特征，而舍弃其非本质的特征的过程。具体地来说，抽象就是人们在实践的基础上，对于丰富的感性素材通过去粗取精、去伪存真、由此及彼、由表及里的加工制作，形成概念、判断、推理等思维形式，以反映事物本质和规律的方法。这里调侃下，当我们试图用哲学的知识去解释一个IT架构概念的时候，组织需要的也许是一个保洁、保安(此处虽然调侃之意，但也可以用架构的业务用例来解释)。我们回过来看定义，重点词圈出来：抽取、共同、本质性特征、实践基础上。我们把主题切换到架构层面，我们如何去解释以下几个问题：
1、架构层面抽取指的是什么？
2、架构层面共同指的是什么?
3、架构层面本质性特征指的是什么？
4、架构层面实践基础上指的是什么？
回答以上问题之前，我们看
Togaf 9.2对抽象(Abstraction)的定义：
The technique of providing summarized or generalized descriptions of detailed and complex content.
Note:
Abstraction, as in "level of abstraction", can also mean providing a focus for analysis that is concerned with a consistent and common level of detail or abstraction. Abstraction in this sense is typically used in architecture to allow a consistent level of definition and understanding to be achieved in each area of the architecture in order to support effective communication and decision-making. It is especially useful when dealing with large and complex architectures as it allows relevant issues to be identified before further detail is attempted.
1、抽象看成了一种解决复杂内容(这里翻译为问题可能更好)的技术
2、抽象可以为每个架构领域中形式一致性定义和理解（本质是知识语境的说明）
感觉这个定义更多的是在讲抽象在架构中的作用，而不是在回答在架构层面什么是抽象。从这个定义来看，对Togaf还是挺失望的。继续深挖，
Togaf 10对架构抽象有定义:
An architectural technique for dividing a problem area into smaller problem areas that are easier to model and therefore easier to solve.
Abstraction levels are layered in nature, moving from high-level models to more detailed models.
Architecture effort can be divided into four distinct abstraction levels that cross the Business, Data, Application, and Technology domains to answer fundamental questions about an architecture:
- Why — why is the architecture needed?
- What — what functionality and other requirements need to be met by the architecture?
- How — how do we structure the functionality?
- With what — with what assets shall we implement this structure?
Note that why, what, and how have no connection to their use in the Zachman® Enterprise Architecture Framework.
这个定义就有意思很多，至少完全从架构视角去解释的。
1、把问题域划分为更小问题域一种架构技术，抽象的本质是分层，从高阶模型转移(moving from)到详情模型。
这个解释虽然比9.2更好了，笔者理解划分的本质就是架构分治，用架构分治来解释架构抽象？？另外转移笔者理解用conext map 更恰当，从高维度解释低维度问题。关于架构四个层面抽象下面这张图更清晰些：
1、上下文抽象层
2、概念抽象层
3、逻辑抽象层
4、物理抽象层
业务架构、数据架构、应用架构、技术架构分别要回答架构抽象的四个层面。
笔者认为上面的定义还是比较模糊，架构抽象作为架构思想的重要部分，我们期望其定义能指导我们如何去做架构（特别是新的业务领域），并且把现有相关的架构框架体系的元素、工具关联起来，且能落地到具体的业务上。
架构抽象定义：
在了解事物全貌后对事物特征进行共性抽取、泛化的过程。
我们再来看从业务层面抽象定义：
业务架构层面架构抽象的定义：在了解业务全貌后对角色、业务活动、业务规则 、业务流程进行共性抽取、泛化的过程。
DDD战术层面架构抽象的定义：在了解领域知识后，对领域实体、值对象、聚合根进行共性抽取、泛化的过程。
大家兴趣的，可以基于这个定义扩展到不同的概念中。我们再回来看上面的问题如何回答
1、架构层面抽取指的是什么？
抽取：从分层视角来看，抽象是把共性特征聚合到更高层次。
2、架构层面共同指的是什么?
共同：事物相同的特征
3、架构层面本质性特征指的是什么？
本质性特征：承接业务能力的核心业务对象相关属性。这里一定要从组织、业务视角来看。
4、架构层面实践基础上指的是什么？
领域知识或者说是参考架构
架构抽象是一个过程，那用什么可以体现整个抽象过程的结果呢。答案就是我们输出不同的架构视图，如：业务架构图、应用架构图、领域架构图等。
这里引出一个问题，我们经常发现，不论是从架构层面、代码层面都做了很好的抽象并且引入了合适的架构模式、设计模式，但每次需求变化的时候都需要做一次重构优化。这时就会被领导怼、产品经理说不懂复用、抽象。这个问题要从组织、业务两个视角去回答，已经超同本文标题范围了，以后有时间再写。
引用：
抽象（哲学概念）_百度百科 (baidu.com)
TOGAF® Standard — Introduction - Core Concepts (opengroup.org)
TOGAF 10 Courses Foundation and Practitioner (detecon.com)
The TOGAF Standard, Version 9.2 - Definitions (opengroup.org)
