网站特点

发现一个帮助更好思考问题的工具「untools」，收集了各种思维工具和框架，可以帮助我们更好地理解问题、分析、决策，包括有常用的金字塔、鱼骨图、二阶思维等，类似于选择不同的思维模型来解决不同的问题。

网站结构

系统思考

• 概念地图（Concept map）: 形象地理解一个概念或系统，了解其实体之间的关系。
• 连接圈（Connection circles）:是一种将故事或系统中的关系可视化的工具。它们通过看到系统中的因果关系来帮助你理解复杂性。
• 冰山模型(Iceberg Model):通过查看隐藏的抽象级别来发现事件的根本原因。
• 平衡反馈回路(Balancing feedback loop):是一种机制，它抵制在一个方向的进一步变化。它以反方向的变化来对抗一个方向的变化。它试图稳定一个系统。
• 强化反馈回路(Reinforcing feedback loop):了解指数（复利）变化背后的力量。

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

3. 场景联动类

在中台业务域中，有许多与C端紧密相关的场景，但我们似乎并未抓住这种适合互动的机会，前中后台之间缺乏沟通与联动。整个系统就像一座冰山，前台只是冰山一角，冰面之下隐藏着庞大的中台系统，这就形成了前后之间虽然关系紧密但彼此看不见的情况。

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

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