摘要：
关于逻辑架构的分层、分区和机制。主要关于机制，他的定义是为了完成某一目标、基于抽象角色的协作方式和流程。可以理解为是基于角色和USECASE的功能流程。有两个关键词，一个是角色，另外一个是流程。 阅读全文
posted @ 2020-06-12 18:01
忒儿
阅读(147)
评论(0)
推荐(0)
摘要：
关于鲁棒图。他弥补了从用例到交互图之间的缺失。交互图非常的复杂，因为它会有很多场景，是一个非常重的图，我不建议用在常规的设计里面，除非是一些核心的交互场景，而且是那些不易经常发生变化的。鲁班图可以识别出来对象和过程，相当于把用例更细化掉。后面可以做做推广实践。他定性成系统的初步设计，没啥问题。 关于 阅读全文
posted @ 2020-06-12 18:00
忒儿
阅读(115)
评论(0)
推荐(0)
摘要：
关于分阶段，每个阶段在多视图。我觉得做一件事情是要以时间轴来看。更广泛一点，应该是主题来看。一个主题，我们可以有多种视角。拿时间来说，我们确实会分步骤去做长期的实施计划。 关于二维需求矩阵。一个维度是功能质量约束，没啥问题。但另外一个维度是说组织、用户和开发，这里问题比较大，因为从理论上来说，我们应 阅读全文
posted @ 2020-06-12 17:58
忒儿
阅读(161)
评论(0)
推荐(0)
摘要：
1 可修改性理解 可修改性理解可理解为：指系统或软件的能够快速地以较高的性价比对系统进行变更的能力。比如说：对于一个网站，我们要修改它某一板块的UI界面，当我们对界面进行修改时是否会引起对另一个UI模块的影响，是否会引起后台控制，业务逻辑代码的变更，是否会引起整个网站的崩溃，这体现了一个网站的整个架 阅读全文
posted @ 2020-06-12 17:55
忒儿
阅读(148)
评论(0)
推荐(0)
摘要：
摘要：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 面 阅读全文
posted @ 2020-06-12 16:23
忒儿
阅读(215)
评论(0)
推荐(0)
摘要：
摘要：MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑 阅读全文
posted @ 2020-06-12 16:13
忒儿
阅读(182)
评论(0)
推荐(0)
摘要：
架构产生的动力： 必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了） 每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有 阅读全文
posted @ 2020-06-12 16:00
忒儿
阅读(131)
评论(0)
推荐(0)
摘要：
为什么会产生架构？ 想象一下，在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活 阅读全文
posted @ 2020-06-12 15:55
忒儿
阅读(105)
评论(0)
推荐(0)
摘要：
架构漫谈是由资深架构师王概凯Kevin执笔的系列专栏，专栏将会以Kevin的架构经验为基础，逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题。 缘起 一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬 阅读全文
posted @ 2020-06-12 15:54
忒儿
阅读(145)
评论(0)
推荐(0)
摘要：
先利其器 适当使用数据库 关系型数据库 适用 当需要ACID属性来保证数据之间的关系和一致性时 优势 提供了高度的事务完整性，支持sql，可用于发杂查询 缺点 难以扩展 成本高 海量数据效率低 非关系型数据库 适用 不需要关联其他数据，也不需要事务完整性 优势 无需sql层解析，读写性能快，存储格式 阅读全文
posted @ 2020-06-12 15:49
忒儿
阅读(100)
评论(0)
推荐(0)
摘要：
架构之术 大道至简 避免过度设计 如何界定过度：设计是否浅显易懂，是否让人可以快速理解还是过于复杂 表现为把一件事做的过于复杂和以复杂的方式去完成一个任务 在设计中要警惕复杂的解决方案 在这一块儿的感触还是比较深的，在之前自己参加比赛的时候，为了给程序加一个漂亮的界面，使用了一个不懂的框架，在没有成 阅读全文
posted @ 2020-06-12 15:47
忒儿
阅读(101)
评论(0)
推荐(0)
摘要：
架构的根本 架构的根本在于人 可扩展性的关键是人 人增加越多，每个成员的单位沟通和协调成本就越大。尤其个性解放的年代，每个小伙伴的性情各异，成长背景，工作经历都不尽相同，所以导致成员间的性格差别，做事风格迥异，要大家统一遵守一个规则，显得相对困难，所以耗费在沟通和协调的成本不断变大。 合适的人，在合 阅读全文
posted @ 2020-06-12 15:42
忒儿
阅读(145)
评论(0)
推荐(0)
浙公网安备 33010602011771号