架构学习
<h1>架构学习</h1>
<h2>一张表四张图</h2>
<ul>
<li>实体概念定义表</li>
<li>信息架构图</li>
<li>状态流图</li>
<li>功能架构图</li>
<li>业务流程图</li>
</ul>
<h3>产品架构、功能架构和信息架构之间的关系</h3>
<p>产品架构包含功能架构和信息架构，信息架构为功能架构提供实体支撑。</p>
<h2>实体概念定义表</h2>
<h4>实体和概念有什么关系？</h4>
<ul>
<li>实体是显示概念在数据模型中的抽象表示</li>
</ul>
<h4>如何绘制实体概念定义表</h4>
<p>写清楚 实体名，实体类型，实体描述，实体属性，实体状态，关联实体</p>
<h2>信息架构图</h2>
<h4>定义</h4>
<p>信息架构是对产品方案中的抽象实体，进行组织和分类的过程</p>
<h4>如何画出信息架构</h4>
<ul>
<li>自顶向下：先从最可能满足产品目标的内容或实体进行分类，再按逻辑细分出次级分类，层层展开</li>
<li>自底向上：先把所有实体写出来，放在最底层，再将它们归属到较高一级的类别中，层层向上归纳。</li>
</ul>
<h4>信息架构示例</h4>
<pre><code class="language-mindmap"># 抖音
## 内容
### 媒体类
#### 短视频
#### 图文
#### 直播
### 商业类
#### 团购
## 商品
### 链接
## 人
### 属性
### 作品
### 关系
#### 粉丝
#### 关注
## 消息
### 系统消息
### 用户消息</code></pre>
<h2>状态流图</h2>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=f0de6ed7253c5c062632f16913319ae6&file=file.jpg" alt="uml" title="uml" /></p>
<h4>定义和组成元素</h4>
<p>状态流图主要用于描述一个对象和在其生存期间的动态行为，表现为一个对象所经历的状态序列、引起状态转移的事件，以及因状态转译而伴随的动作，一般可以用状态机对一个对象的生命周期建模，状态图用户显示状态机，重点在于描述状态图的控制流</p>
<h4>注意事项</h4>
<ul>
<li>不用追求完全符合UML规范，能让沟通对象理解即可</li>
<li>不用对所有实体都画状态流图，只给哪些比较核心、复杂、状态比较多的实体画即可</li>
<li>一个框中只包含一种状态，一个实体同时包含多个状态时，建议绘制多张状态流图</li>
</ul>
<h2>功能架构图</h2>
<h4>定义</h4>
<p>是按照功能的从属关系画成的图表，一般情况下产品或者系统的总共能可以分解为若干功能，各分功能又可以进一步分解为若干二级功能，如此继续，直至分功能被分解为功能单元模块为止，这种由分功能或功能单元按照其逻辑关系连成的结构成为功能架构，分功能或功能单元的相互关系可以用图来描述，表达分功能或功能单元相互关系或从属关系的图为功能架构图</p>
<h4>画功能架构的步骤</h4>
<ul>
<li>明确产品目标</li>
<li>设计解决方案</li>
<li>抽象核心功能</li>
<li>拆分功能结构</li>
</ul>
<h4>画功能架构图的注意事项</h4>
<ul>
<li>根据目的不同，有自顶向下和自底向上两种画法</li>
<li>前台架构更加关注功能和页面逻辑，后台架构更加关注角色和业务规范</li>
<li>功能架构和界面布局不是一回事，二者有重合，但面向对象不同</li>
</ul>
<h2>业务流程图</h2>
<h4>定义</h4>
<p>通过特定的符号和连线，业务流程图可以用来描述产品使用时，各角色、系统之间的业务关系、作业顺序和信息流向</p>
<h4>目的</h4>
<ul>
<li>将实际产品满足需求的过程抽象化、便于梳理、完善产品设计思路</li>
<li>将想实现的业务步骤可视化，便于和业务沟通想法</li>
<li>细分功能模块的实现逻辑，便于实施人员开展工作</li>
</ul>
<h4>组成元素</h4>
<p><img src="业务流程图的组成元素" alt="" /></p>
<h4>业务流程图绘制思路</h4>
<ul>
<li>定于角色： 明确整个流程中，都有哪些或哪些系统会参与，一般来说，任何系统角色，都会出现在流程图中，以人在系统中的任务流转为主，系统和系统之间的任务流转为辅</li>
<li>定义行为：指角色在业务流中需要执行的具体事情</li>
<li>定义分支条件：指角色在执行操作，产生行为时，由于进行了不同条件的选择，而出发的流向变更</li>
<li>流程连线： 把每个角色，在不同分支条件下，产生的行为流转规则，用线连接起来，就是一套完整的流程图</li>
</ul>
<h4>画业务流程图的注意事项</h4>
<ul>
<li>先梳理主流程，再补充分支流程和异常流程，完后要和业务方、实施方反复确认和修改，知道没有遗漏</li>
<li>菱形判断框不要过多或过少，2-3个为优，走向条件写在箭头线上</li>
<li>流程图可以很长，但整体应该是自上而下顺序进行，尽量不交叉，如果逻辑功能比较多，必要时可以分层绘制主流程和子流程</li>
<li>绘制完成后，可以尝试找到流程中冗余、低效、浪费的环节，然后想办法简化、提高效率</li>
</ul>
<h3>做产品架构的建议和心得</h3>
<ul>
<li>做好架构的关键是理解业务、理解需求，前期调研准备最重要</li>
<li>产品经理对架构能力的掌握程度，在于是否抽象层级足够深、抽象维度足够多、异常流程考虑的足够全，这需要长年累月的训练总结</li>
<li>懂一点软件工程、数据库、技术实施原理，总没坏处</li>
</ul>