远程Service组件不应该互相调用
因为互相调用可能会造成执行时的无限循环,比如 1.Component A下面的 service A1 调用了 Component B下的service B1 2.Component B下面的 service B2 调用了 Component A下的service A2 这样看没什么问题; 但某一天某个不知情者让B1调用了B2,另一个不知情者则让A2调用了A1, 就有可能在执行时造成 A1 -> B1 -> B2 -A2 -> A1 这种无限循环
Architecture
《软件架构设计》读书笔记 – 4. 关于非功能需求
《软件架构设计》温昱著 ================================================= 非功能需求可分为： 1.约束 2.质量属性 a.运行期质量属性 b.开发期质量属性 先说下约束。约束会从三种途径影响设计： a.设计可以直接遵守约束，比如“必须运行在Linux上” b.约束转换为功能性需求，比如“系统必须严格按人行利率执行” => “必须提供利率调整的功能” c.约束转换为非功能性需求，比如“操作者的计算机水平不高” => “必须有良好的易用性” 关于质量属性，作者创新地把它们分为运行期属性和开发期属性： a.运行期: Performance, security, usability, availability, scalability, interopreability,reliability, robustness b.开发期: Understandability, extensibility, reusability,testability, maintainability(可被修改的难易程度), portability
《软件架构设计》读书笔记 – 5. 关键需求决定架构
《软件架构设计》 温昱 ============================================ 等分析完所有需求才进行架构设计，一般是来不及的；应该针对关键性需求在有限的时间内做出可用的架构设计。至于非关键性需求，可以把它们用来验证架构：从每项非关键需求的角度对架构方案进行走查。 那么哪些需求是关键性需求？ 1.约束，因为它们必须被满足 2.关键Use Case 3.需求方眼里的高优先级需求 4.对系统受认可程度有较大影响的质量属性
VIP
转自WIKIPEDIA virtual IP address (VIP or VIPA) is an IP address that is not connected to a specific computer or network interface card (NIC) on a computer. Incoming packets are sent to the VIP address, but they are redirected to physical network interfaces. VIPs are mostly used for connection redundancy; a VIP address may still …
框架设计的核心原则之一：indirection
有句话叫做： "All problems in computer science can be solved by another level of indirection" 最近学习了一些框架，很多地方都暗合了这句话。我把我能理解的外延列举一下： 1. 通过indirection避免diretion所需的复杂性。比如通过操作系统访问硬件比直接机器码操作硬件要简单的多。 2. 通过抽象的indirection，达到具体实现的多样性以及可插拔性。比如一个DAO可以用hibernate实现，也可以用ibatis实现，上层不必关心。 “抽象化”不限于OO领域，任何有共性的东西都可以抽象成同一种东西，比如，URL/文件路径都可以抽象成“资源”；JVM也是一个著名的例子。 3. 你表面上在使用一种东西，但在背地里，你的框架却偷偷地通过indirection思想，通过另一种东西来为你服务。这就是“ 虚拟化”，它的好处是可以让你用你熟悉的方式去使用服务。举些例子： a.你以为你的程序跑在一台普通电脑上，实际上那不过是个VMWare而已 b.看上去你写的SQL都基于单个数据库，实际上你的DB早就被分库、分表的面目全非了，只不过你的架构师自写了一套jdbc driver，屏蔽了这些复杂性而已。
《软件架构设计》读书笔记 – 3. 典型的差的软件架构
《软件架构设计》温昱著 差的软件架构的常见的毛病： 1.急着设计，导致遗漏了一些非功能需求 2.着急，可扩展性没做好 3.多视图中只考虑了部分视图。比如用户感觉好，但开发人员和SCM被搞的很痛苦 4.未经初步验证就投入使用，到后期才发现架构不可行。其实应该在图画好之后作个垂直原型来验证一下
《软件架构设计》读书笔记 – 2. 软件架构的多视图
《软件架构设计》温昱著 软件架构需要多个视图，以面向不同的受众，并解决不同的问题，或者问题的不同的方面 本书认为软件架构的服务人群有以下几种： 1.终端用户 – 架构要满足功能、性能、易用及其它质量属性 2.甲方 — 软件要满足买主的业务目标 3.开发人员 — 这就不用说了 4.软件配置人员/运维人员 5.管理人员 — 这是因为系统架构往往决定开发人员的组织结构 ========================== 作者认为架构有5种视图，跟MDA的4+1比较吻合： 1.逻辑架构 — 相当于Logical View 2.开发架构 – 相当于Implementation View 3.运行架构 — 相当于Process View 4.物理架构 — 相当于Deployment View 5.数据架构 — 无 6. 无 — Use-Case View
《软件架构设计》读书笔记 – 1.定义和其它一些基本概念
《软件架构设计》温昱著 1.软件架构的定义有两点主要内容: a.架构是component及component之间的交互，如“此系统可分为三层”，“WEB层采用了MVC“模式 b.架构是一些重要方面所作出的决策的集合,如“这样设计是为了实现可扩展性” 2."好的架构必须使关注点分离”，这是三个维度的事情： a.通过职责来划分系统，比如分层（用到设计模式、架构模式） b.在不同粒度上划分成类、模块、子系统(组件技术, SOA技术） c.分离出通用部分和特定应用部分（所以才有了框架）
如何让框架既适用于大多数情况又适应少数情况 — 局部优先原则
如何让框架既适用大多数情况和少数情况 ? 比如大部分页面的布局都是default.jsp, 如何让某些特定页面使用自己的布局，但又不会绕开框架？ 一个普适的设计原则就是“局部优先原则（我自己取的名字，不正规）”： 框架在查找布局时先查找与当前页面最接近的布局jsp，找不到再按一种规则查找上一层，直到找到default.jsp 从框架设计者的角度来看，装载布局的逻辑没有根本性变化，只不过定位布局jsp文件时采用了新的规则 从框架使用者的角度看，他们现在可以用局部的东西“覆盖”全局的东西
Domain Driven Design — 一页写完的笔记
Model是什么： 1.业务知识的提炼 2.团队内部良好沟通的基础 =================================================== Ubiquitous Language: 用同一套语言，减少不必要的翻译和误会，促进沟通效率 1.讨论需求时，开发人员与业务人员之间、开发人员与开发人员之间用同一套术语进行交流 2.代码中的元素如类、变量，也要用需求中的术语来命名 =========================== 设计中的基本元素： 五个基础要素： 1.Entity 2.Value Object 3.Service 4.Factory 5.Repository 注意Aggregation的概念：一个Agrregation代表一个由多个对象组成的整体，它有一个根对象作为外部访问它的入口。 =========================== 使Model更精炼： 1.使Implicit Concepts变得Explicit，比如从“下载一个文件，并记录开始时间和结束时间”可以挖掘出“任务”的概念 2.使用Strategy模式，把算法作为概念 3.应用Analysis Patterns =============================== 多个Model之间的一致性问题：每个团队都有自己的domain model(一个model称作一个bounded coontext)，如何让它们协作？ （这一部分对SOA实践者可以有帮助） bounded context之间的关系有以下几种模式： 1.Shared Kernel: 共享一部分核心Model, 好处是避免重复开发，提高效率；坏处是一方改变Kernel时可能会对另一方造成较大影响 …