在做中台设计的过程中，发现中台体系庞大，链路错综复杂，问题也很多。不过这些页面之间都存有一些共性，通过对页面特征的分析，总结出了三种典型的业务场景类型：信息列表类、规则配置类、场景联动类。

2. 规则配置类

规则配置类页面是中台业务域中另一种常见的场景，其特点是配置项繁多，且逻辑复杂。繁琐的配置加上复杂的逻辑无疑加重了用户的认知负荷，导致操作低效。
复杂的规则让我们看不懂配置项背后的含义，这类现象统称为“看不懂”。针对该问题，我们意识到可以利用人眼对图形符号更为敏感这一特性，用图形符号代替文本描述，让抽象的概念和复杂的逻辑关系清晰可见，以此来降低理解门槛。
为了更好的帮助我们理解图形符号映射法则，下面举个案例加以说明。

案例  选品特征组合可视化

在做中台设计的过程中，发现中台体系庞大，链路错综复杂，问题也很多。不过这些页面之间都存有一些共性，通过对页面特征的分析，总结出了三种典型的业务场景类型：信息列表类、规则配置类、场景联动类。

1.信息列表类

列表是中后台最为常见的场景之一，传统的列表无非是字段的堆叠，大量相似信息的重复出现，降低了有效信息的捕获和整合效率，加重了认知负荷。大量列表让我们有种看不清重点的错觉，这种现象统称为“看不清”，为了解决这个问题，我们将列表按照其功能分成两大类：执行类和看板类。执行类列表目的是将所有字段展示完全，方便统一管理和操作；看板类则只要展示关键信息，起到快速查看和监控的作用。

1.1 执行类列表

这里举一个营销列表的例子，营销列表的作用是对所有的活动进行一个高效的管理。

vim 中可以使用 ：s 命令来替换字符串。以前只会使用一种格式来全文替换，今天发现该命令有很多种写法（linux vi命令真是强大啊，还有很多需要学习），记录几种在此，方便以后查询。

：s/vivian/sky/ 替换当前行第一个 vivian 为 sky
：s/vivian/sky/g 替换当前行所有 vivian 为 sky

：n，$s/vivian/sky/ 替换第 n 行开始到最后一行中每一行的第一个 vivian 为 sky
：n，$s/vivian/sky/g 替换第 n 行开始到最后一行中每一行所有 vivian 为 sky
n 为数字，若 n 为 .，表示从当前行开始到最后一行

：%s/vivian/sky/（等同于 ：g/vivian/s//sky/） 替换每一行的第一个 vivian 为 sky
：%s/vivian/sky/g（等同于 ：g/vivian/s//sky/g） 替换每一行中所有 vivian 为 sky

可以使用 # 作为分隔符，此时中间出现的 / 不会作为分隔符：s#vivian/#sky/# 替换当前行第一个 vivian/ 为 sky/
：%s+/oradata/apras/+/user01/apras1+ （使用+ 来 替换 / ）： /oradata/apras/替换成/user01/apras1/

企业服务在解决什么问题？

按照亨利·法约尔的说法，无论哪种类型的企业，经营的过程中都会面临这6种活动：技术活动、财务活动、会计活动、商业活动、安全活动、管理活动。

市场上主流的企业服务产品解决的问题分别是：

• Salesforce、纷享销客解决的是企业的商业活动，帮助企业把产品卖出去，或把产品（资源）买进来。
• 金蝶、用友解决的是企业的会计活动，帮助企业把账记清楚，各项成本是多少、有多少负债与资产。
• Teambition解决的是企业的管理活动，帮助企业把事（项目）理清楚，提高团队协作效率。同样是解决管理活动，薪人薪事的不同点在于它解决的是人的问题，帮助企业把人员的管理变得更高效。

即便了解了这个理论，在对市场规模进行预判的时候我们还是会犯错，因为企业发展的不同阶段，每个经营活动的侧重点是不一样的。以互联网公司为例：

• 早期，想法要落地首先需要启动资金，于是企业发展的第一步就是准备BP融点钱，然后开始招聘，租办公场地，购买服务器等设备，所有人的精力都扑在产品上，公司最重要的资产就是产品和技术人员，这个阶段企业最关注的是财务活动和技术活动。
• 产品打磨的差不多了，下一步准备开始推向市场了，于是要开始考虑哪些渠道推广更有效，涉及到付费的话还要考虑定价策略，因此这个阶段企业最关注的是商业活动，即把产品更好地『卖出去』
• 一旦产品被市场证明是有效的话，企业会开始考虑规模化复制以便迎来更快的增长。而随着规模的扩大，不可避免会出现组织的『熵增』，于是大家开始关注如何提高企业运转的效率，哪些关键岗位需要更专业的人，哪个环节的效率可以优化。这个阶段企业最关注的是商业活动和管理活动。

介绍

很久以前就注意到了这个网站：B端观止,有很多有关于B端设计的文章，对于产品设计也很有借鉴意义。最近又看了一下，比较可贵的是，一直在更新。推荐查看。

推荐文章

• 权限设计指南
• 低代码开发平台设计初探索
• 场景理解模糊？看完这篇就够了！

概述

领域驱动设计DDD在战术建模（后文简称建模，除非特别说明）上提供了一个元模型体系（如下图），通过这个元模型我们会对战略建模过程中识别出来的问题子域进行抽象，而通过抽象来指导最后的落地实现。

这里我们谈的战术阶段实际就是这样一个抽象过程。这个抽象过程由于元模型的存在实际是一定程度模式化的。这样的好处是并非只能技术人员参与建模，业务人员经过一定的培训也是完全可以理解的。在带领不少团队实践建模的过程中，业务人员参与战术设计也是我要求的。
由于已经有不少书籍介绍DDD的元模型，这里我们就不再赘述，转而谈谈这个抽象过程中大家经常遇到的一些困惑。这些比较常见的问题可能是DDD元模型未来演进需要解决的，但我们仍然要注意业务问题和架构设计的多样性，不要过度规范，以至于过犹不及。

为什么要解耦

在软件开发领域，解耦这个词相信大家都不陌生。在面向对象的语境下，我们会应用SOLID原则来构建高内聚低耦合的应用，实现模块间的解耦；在复杂业务系统分析和建模时，会通过DDD的战略和战术设计帮助划分领域并实现分布式系统中服务的解耦；当我们在组织大型敏捷开发团队协同工作时，通过组建自治团队来减少摩擦，从而实现团队级别的解耦。

可以看到解耦无处不在，并且以此为目的投入，大家都会觉得是无比的政治正确，因为实现了解耦，我们的系统和应用就能更快速的扩展和演进，我们的团队就能更顺畅的合作并能更加快速的实现业务价值。

但是，当我们暂时抛开将得到的种种好处，思考要如何去实现它时，却发现解耦这个词表达的意义过于抽象和模糊，它既没有描述最终的状态也没有提供实现的方法。那当我们谈解耦的时候，具体内容是什么呢？

从字面上理解的所谓耦合，通常是指两个或两个以上的物体或者体系之间相互作用彼此影响，对应到软件研发的以上场景，我们可以转换成是指两个或两个以上的模块/系统/团队之间相互作用彼此影响。

在软件需要解决的业务问题越来复杂的今天，单个的系统或者团队很难在不依赖外部的情况下去实现业务目标，所以我理解的解耦并不是要消除耦合(彼此的作用和影响/依赖)，而是指我们应该如何通过一定的方式和规则，来设计和管理以上提到的多个元素之间的依赖，降低耦合程度来使整个系统有序顺畅的运转。

本文将从服务间上下游的思维来讨论如何在系统架构演进过程中，持续的保持服务间的松耦合，实现解耦的目标。

图标素材网站

Bootstrap 官方图标库

网址：icons.bootcss.com

什么是上下文映射

上下文映射，对应的英文单词是Context Map，代表的是领域驱动设计中，多个限界上下文之前的关系。方便设计者和开发者能够一目了然地看到每个限界上下文和其它限界上下文之间的关系，最终的产出可能是一张映射图，或者映射卡片。实际上的限界上下文映射的设计，不只是跟设计决策和技术实现有关，还跟企业文化、组织架构有关。

有哪些上下文映射

分离方式

分离方式（separate way），分离方式指的是两个限界上下文没有任何关系，没有关系其实就是一种非常好的设计，因为它们可以独立变化，互相影响。
但在实际的开发过程中，可能两个限界上下文会有一些耦合。如果设计者认为这两个限界上下文解耦的价值远远大于复用的价值（比如分属于两个差异很大的团队），那可以通过引入少量的重复来彻底解耦开来。
比如：在电商场景中，支付上下文，就和库存上下文没有任何关系。

客户-供应

客户-供应（customer/supplier）是我们最中间的一种上下文映射方式。一方提供服务，另一方去调用服务。我们类比水流，上游发生变化可能会影响下游，所以我们把提供服务的一方称为“上游”，使用服务的一方称为“下游”。这与调用关系刚好是相反的。
比如：在电商场景中，订单上下文依赖库存上下文，所以库存上下文就是订单上下文的上游。

发布-订阅

发布-订阅（publisher/subscriber）也是一种很常见的上下文映射方式，在实际的开发过程中往往是通过消息中间件来实现。
发布-订阅模式源自于设计模式中的“观察者模式”，上下游通过消息去通信，下游注册观察者，上游作为发布者，如果上游发生了变化，会发布一个业务事件，下游收到这个事件后进行后续的操作。
发布-订阅模式与客户-供应模式最大的不同，在于发布-订阅模式，是上游主动发起业务的变化，而不是被动等下游去调用上游。它相较于客户-供应模式而言，耦合程度会低一些。
比如：在电商场景中，订单上下文和物流上下文，就可以通过发布-订阅模式来做。订单完成后，发生订单完成事件，物流上下文监听事件开始物流配送。

概念：

维度退化（Degenerate-Dimension,DD）：将维度退化到事实表中，减少事实表和维度表的关联，在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

特点/举例：

退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。

特点：

1. 没有对应的维度表的维度。
2. 存储在事实表中