yimlin
- 浏览: 139185 次
- 性别:
- 来自: 福州
-
最新评论
-
semmy：
牛人，我的偶像
关于架构的思考 -
mercyblitz：
引用1. SPI和API存在业务不匹配问题。虽然组件A依赖组件 ...
企业应用下的业务组件开发实践 -
凤舞凰扬：
楼上初步总结了一些，我本来有想法打算写一个架构师之路系列 ...
浅谈企业应用架构（一） -
lgch123：
做伟大的事业，不是说说就能起来的。
浅谈企业应用架构（一） -
hanyou：
写的非常好，如果你是原版，那么你肯定从事了多年的开发，有丰富的 ...
浅谈企业应用架构（一）
文章列表
作者： Anders小明
一、 架构是什么
通常关于架构的第一个问题是架构是什么，很自然也很正常，本文也不能免俗。然而关于这个问题却没有一致性答案，同时也要注意到不同应用的架构实质上存在不同差异性。
(一) 架构的定义
架构，虽然人们一直在讨论它，甚至于每天都在同其工作，然而这个词并没有一个被业界广泛认可的定义。
大致而言，架构的定义分为三类：
类别
定义
结构论
牛津高阶词典: The design an structure of a computer system
作者： Anders小明
在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system。这个解释实际上已经描述了架构的本质：架构是关于怎么做（构成系统）的，而非做什么的。更进一步，架构是由人来设计实施，因此架构实际上是一个文化（culture）——我们怎么认识或理解系统/产品的，并且我们准备怎么做，在做的过程中我们认为什么是好的，什么是好的等等。
任何系统都有架构，无论多小的系统都有。区别在于其架构是否是经过明确设计并表达。一个合理的架构无疑是经过精心设计和维护的，而进行架构设计，或者 ...
作者： Anders小明
什么是企业应用下的业务组件
首先，这是一个组件，这意味着它需要在容器里运行，因此不包括任何中间件服务，同时以一定结构（文件结构或者压缩格式）组成，被容器识别；其次，这是一个业务组件，即提供的是应用服务，而非技术服务；第三，这是企业应用，在业务上包括功能和服务（Service，当前最时髦的说法，你可以理解为API），技术上（以J2EE来讲）包括：UI资源（JSF、JSP、JS和CSS等）、应用程序（Java）资源和配置文件、数据库表定义、初始化数据和存储过程。
为什么要企业应用下的业务组件
组件技术从提出到现在已经有20多年了，为什么要提企业应用业务组件 ...
作者：anders小明2009年5月7日
需求背景
现在的样子
如PoEAA中提到的：事务脚本(Transaction Script)和表模型（Table Moduel）模式。
存在问题
事务脚本看到的是零散的数据，而表模型混合了下文要说领域模型和领域服务界限。
1. ...
作者:anders
2009年5月5日
一、什么是基础平台
基础平台对应于业务应用，主要处理技术问题，是为业务应用提供技术支撑以及技术方案的模块或者组件。其目的是使得应用组件可只关注于业务逻辑，而不考虑或者少考虑技术问题。
基础平台通常包括如下：基础功能，开发类库，开发模式以及开发部署工具。
二、为何要基础平台
应用系统的设计可以说是将一个业务语言翻译成程序语言的过程，这个过程同时处理两个内容：业务和技术。
1. 学习业务，编写的代码符合用例的流程；
2. 学习技术，编写的代码符合技术平台的规范和要求。
作者：Anders小明2009年5月5日五、架构的技术层面
（一）基础手段
提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点，好处不用说了，可以并发的工作，每个人面对的问题都简单而容易操作。而与分解 ...
作者：Anders小明2009年5月5日
一、什么是架构
在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system，而架构师（architect）一词的解释是：a person who is responsible for planning or creating an idea, an event or a situation。
针对于企业应用，依据不同的关注点，架构可以分为如下几类：
业务架构（Business Architecture）：关注于业务及其流程；
应用架构（A ...
Author：Anders小明
目前采用是面向对象设计方法，设计的粒度分为两级：类和方法（属性），类似于数据库设计的表和字段；
在现有实现体系下，一个方法内部将包容多个Use Case；同时因为Use Case本身的横向扩展，也会导致一个Use Case将关联到多个方法；这是一个多对多的关系，为我们的开发管理带来巨大的成本。
为了有效管理Use Case及其实现映射，AOP技术成为一个好的选择；AOP允许我们为每个Use Case建立起独立的可管理的设计粒度：从方法中的一个代码段升级为一个独立方法和类；并允许这些Use Case被合理的有序的组织。
现有的技术体系已经为我们建立了可行方案 ...
Author：Anders小明
（2008-1-12更新）
业务流程依据不同层次分为3个
0. 领域流程
领域流程即领域对象生命周期，是流程中的核心；
1. 工作流程
工作流是处理多人协同工作，三权分立的过程；该过程是建立在领域对象生命周期上；生命周期的不同状态在工作流中都有映射；工作流处理的是领域中Request对象的生命周期；
2. 页面流程
页面流是处理工作中一个工作请求的分步申请；该过程建立在工作流上，是其人工节点的UI代理；
这3个不同层次的流程，关注各自处理不同类型的领域对象；页面流在最外层关注于Request对象的数据收集，而工作流则负责Request对象的生命周期，在不同工 ...
Author: Anders小明
（2008-1-12更新）
从以上的分析中，我们可以了解到Domain Model分为三种类型：
0. 全局常量对象
1. 长生命周期业务对象（类似保单对象）；
2. 交易过程的Transaction对象，几乎没有生命周期的；
3. Request/Response对象。 ...
Author：Anders小明以前写过一篇《基于抽象的分层结构》，这里补充一篇《基于业务模块组件的系统架构》一些内容在《项目笔记：dao，web，模块边界以及Model分类》以及《模块的接口设计》随笔中已经提到，这里补充总结一下。任何一个有一定规模系统，通常会把系统做一定分解降低分析设计开发的难度，模块划分是一个比较常见的方式。而在模块的划分及其分析设计的实践中，包括了两种层次的边界。第一是交互行为层次，第二是对象层次。首先说交互行为。模块和模块的交互接口最为重要，通常我们认为这些接口应该通用稳定，然而如何设计每个模块对外提供的接口却是一个不易的问题。集成的两种基本实现方式：1. API方式。这 ...
Author: Anders小明
为何要Domain Model
传统的开发方式：基于数据库的设计开发。数据库提供的设计模型是表和字段两种粒度，这两种粒度有时并不合适于系统设计：
1. 模型的结构化能力
1.1. 同一模块组件下的设计优势；一个model可以来自多张表的数据聚合而成，一张表可以聚合多个Model；一个逻辑是由几个固定字段或者非固定字段聚合；Model间的关联关系也是使用表无法展示的（外键的约束对于系统开发来说实在太有限了）。而这些不论表还是字段粒度都无法支持的！
1.2. 采用Model方式容易解决项目的集成问题（两个不同模块组件访问同一张表的情况）
2. 架构的结构化能力
...
作者：Anders小明(2007.12.14日补充更新了部分内容，其中有关Web网站性能特点部分内容来自网络) 一、什么是架构1. 和架构相关的几个问题域架构需要解决的非业务问题域包括如下：A 系统目标：系统性能，稳定性.B.项目目标：开发成本，质量C.项目过程：需求的不确定性和开发过程的团队协作性不同的问题域，解决之道也不相同！而同一问题域的不同层次的要求，解决之道也不尽相同。2. 什么是架构 架构到底是啥，愚以为下面的这段英文描述的很清楚。That's like asking, what is culture? Culture is the way you do things in a ...
Author：Anders小明软件工程中的经济行为1. 在传统财务概念下，软件公司或者商业公司IT部门的员工，是公司的成本中心。对于一个定额合同项目，员工工资成为项目中唯一的可变成本。2. 因此，尽可能的缩短工期，减少人员投入就成为缩减成本的基本方式。3. 软件的分工模式，以及传统的waterfall——流水线的工作方式，决定了问题发现的越早，修正的成本越低。4. 有两种手段来减少工期，工程上采用迭代，并让迭代周期尽可能短，以及从技术上对于问题域进行分解，建立有效的边界。5. 迭代周期减少的目的是减少分工环节中尤其是第一个环节的不确定性带来的问题，而对问题域的技术分解是解决开发环节的质量问题。因 ...
Blog好久没有更新了, 最近一直忙于一个新项目,在这个项目中尝试很多新的做法,准备收集一下放上blog来,这里先放一篇关于Web框架的,基本是老调重谈了. 该文写于4月,主要是为了和朋友讨论问题,有些地方可能不正确
Struts
JSF
Tapestry
...