软件架构乱弹——问题域及其解决方法

本文讨论了软件架构中的关键方面,包括对象的抽象和集成、依赖关系的处理、流程分解与集成,以及进程边界的管理,如用户请求重定向和业务数据的持久化。同时,文章涉及到了session管理、负载均衡技术以及spring、osgi框架在架构中的应用,并强调了单元测试和测试的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

作者: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 group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions,
Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.
The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.
3. 架构的背后
为了实现架构的目标涉及到以下三个方面:技术,组织和过程。这里举例说明。
1)        技术对开发效率和运行性能,以及组织和过程的影响。
案例A.映射的问题。公司产品的一个重要需求是根据客户输入,映射到PDF文件上。技术上整体实现需要四个步骤:在PDF文件上画好所有的数据域,通过读入一个XML映射文件,获得运行数据并生成FDF,合并FDF和PDF生成目标文件。后两步工作都由代码自动化了,因而实现的主要工作在于前两步。
在第一个实现版本里,XML映射文件的DTD太简单,致使一个xml文件至少在4000行左右,同时xml文件太verbose了。这样的结果直接导致运行系统在峰值时,由于XML消耗了大量内存,1G的内存根本吃不消;同时对XML解析执行使用了CPU的大量时间;导致开发人员需要做大量的工作,开发效率降低了,通常需要尽一周才能完成一个xml文件,员工都不愿意做;也导致开发过程的漫长, 开发部门对于BA部门和ST部门的要求反应变的缓慢。
在第二个版本的实现中,重新实现了DTD,加入了大量的关键字
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值