守株阁

1 用户需求场景分析，识别业务全景 use case。这一个阶段重点识别 actor 和 use case。 2 分析模型鲁棒图，识别出业务场景中所有的实体对象。识别边界类（类似 ui）、控制类（类似 controller）和实体类（类似model）三种类型。 3 领域划分，将所有识别出的实体对象进行分类。 比如，主订单、子订单对象和归类到交易域；买家、卖家对象可以归类到会员域。 当然，最终所有的对象是归类到十个域还是二十个域，从理论上看，可以看做一次排列组合过程。只是，我们往往可以根据以往的经验、业务知识，做一个初始的域划分（但不见得是靠谱的）。因此，我们可以认为一个域实际上是一个或多个实体对象的信息集合，并对所管理的实体对象的生命周期进行管理。 4 评估域划分合理性，并进行优化。域划分并一定总是能得到唯一的答案，但可以得到最好的答案。评价一个域划分方案是不是足够好，其实是要根据“高内聚、低耦合”的原则进行评分。这一步就要画时序图了。 时序图的泳道，应该先设计到域颗粒度。可以看到域之间的交互，也就可以看到域之间的交互的复杂度。在绘制过程中，我们可以看域与域之间的调用是否过于频繁...

https://stackoverflow.com/questions/18618779/differences-between-proxy-and-decorator-pattern https://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. Relationship between a Proxy and the real subject is typically set at compile time, Proxy instantiates it in some way, whereas Decorator is assigned to the subjec...

软件设计，必有单元/片段，不管他们叫做系统、层次、模块、类型和方法，都是为了在一个抽象颗粒度上分割复杂度，让我们降低思考的难度，并且进行团队协作。 我们在进行系统交互的时候，要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性，拥抱间接性。 间接性的实现，就是契约、接口或者门面/桥接模式。这些实践的使用，可以轻易让我们切换层次之间的实现，而使变动不扩散出去。

字符类或者字符集 字符组（character classes） 字符集（character sets） 元字符 metacharacters [abc] A single character of: a, b or c [^abc] Any single character except: a, b, or c [a-z] Any single character in the range a-z [a-zA-Z] Any single character in the range a-z or A-Z ^ Start of line $ End of line 开头结尾：^$，正好对应键盘上的64。 \A Start of string \z End of string . Any single character \s Any whitespace character \S Any non-whitespace character \d Any digit \D Any non-digit \w Any word characte...

同比比较微观，环比比较宏观。 摘自百度： 同比，是指在相邻时段中的某一相同时间点进行比较； 13年和14年是相邻时段，13年3月和14年3月是这两个相邻时段的同一个时间点，都是3月，这两个时段进行数据对比，就是同比； 环比，则相对更简单，就是相邻时间段的对比，不象同比那样，是在相邻时间段内部的某个相同时间点的对比； 14年4月和14年3月是相邻时间段，这两个时间段的数据都比，就是环比；

什么是关键述职 可以决定自己职场命运的述职，一次汇报，就是一个转折点，就是关键述职。 职场不是比拼正确性，而是比拼说服力。 关键述职的误区 把述职当作做了什么的流水账。做了什么不重要，做了什么带来什么价值才重要。一定要解答这个疑问，“所以呢，然后呢”。 把述职当成了邀功大会。只讲价值。 工作成果固然重要，关键能力要看是否有归因和理性思考能力。 方法 So what 找出问题的原因。通过没完没了地问自己，逼迫自己对自己的工作进行深度思考，得出结果，措施。不要怕错。 如何产生这个价值，如何复用这种方法论，如何持续地产生这种价值。 So page 跟公司的战略同步。 不同阶段，重要性是不一样的。 A 求增长 增长期就要看增长率 B 求利润 要看真实效率和投入产出比。 C 求生存，求稳 节衣缩食，勒紧裤腰带过冬。

所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。

DW（Data Warehouse） 数据仓库存储是一个面向主题的，反应历史变化数据，用于支撑管理决策。 ODS（Operational Data Store） 操作型数据存储，存储的是当前的数据情况，给使用者提供当前的状态，提供即时性的、操作型的、集成的全体信息的需求。 ODS 是数据库到数据仓库的一种过渡形式，与数据仓库在物理结构上不同，能提供高性能的响应时间， ODS 设计采用混合设计方式。 ODS 中的数据是“实时值”，而数据仓库中的数据却是历史值。一般 ODS 中储存的数据不超过一个月，而数据仓库为10年或更多。 Data Mart 为特定的应用或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。 DSS（Decision-Support System） 以启发的方式对大量的数据单元进行的分析，通常不涉及数据更新。 参考：https://w...

用例图 泛化(generalization)：泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。 扩展(extend)： extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从子用例指向基用例。 UML Use Case Extend。 包含(include)： include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从基用例指向子用例。 注意，...

步骤 分解（divide）：将问题划分为一些子问题，子问题的形式与原问题一样，只是规模更小。 解决（conquer）：递归地杰出子问题。如果子问题的规模足够小，则停止递归，直接求解。 合并（Combine）：将子问题的解组合成原问题的解。 递归式 递归式（recurrence）可以帮我们刻画整个算法的运行时间。 一个常见刻画递归式的方法是画递归树。通过递归树的枝叶来试图把整个算法的步骤勾勒出来。