Friday, May 09, 2008

读书笔记:Document software architecture

在读一本书,不是教你如何做架构设计,而是如果将系统架构记录下来,但这对架构设计还是很有帮助的,因为你知道了如何文档化一个系统架构,就说明你知道了架构应该包含哪些元素,应该从什么角度来描述架构,这真的很重要,是一种thinking层次的东西,比仅仅会技术还要带劲。
这篇博客是用来作为我的读书笔记, 英文文档已经看完了,但是有些部分太晦涩,用了太多不认识的单词,看的头晕,现在又弄了中文版来对照看。 中文版翻译的一般,有些地方我需要回过去看英文。

[architecture]
什么是架构???
A software architecture for a system is a structure of the system, which comprise elements, relation among them, and the external visible properties of those elements and relations.


[view]

[viewtype]

[style]

[如何描述架构?]
Architects need to
think about their software in three ways simultaneously(同时,一起):
1. How it is structured as a set of implementation units (module viewtype)
2. How it is structured as a set of elements that have runtime behavior and interactions(component-and-connector viewtype)
3. How it relates to nonsoftware structures in its environment (allocation viewtype)

咳咳,先做个记号,有空才写!

2 comments:

脚踏实地 said...

这里,我认为系统架构至少包括两个方面,一个是物理架构,一个是软件架构。从物理架构的角度来看,软件只是很小的一部分,你需要考虑系统健壮,单点失效,路由器,防火墙,集群等等。软件架构主要是指软件的设计。
这里就说软件架构,以前一直在想软件架构是先模块,再分层,还是先分层再模块,这是个问题。现在倒是觉得应该先模块在分层,每个模块包括web(protocal),servvice,domain,dao层,而模块之间的通信只能通过service来进行,同时又应该避免service的相互引用。比如模块A中的一个service需要访问模块B中的一个dao,这个时候我们应该怎么做?直接访问dao当然很简单,但是这就打破了约束,很可能很多其他的模块的service都会直接访问这个dao,如果以后访问这个dao的业务逻辑需要变化,比如对dao关联的bean的数据进行某个校验,那么这个业务逻辑加到哪里? dao么?dao不应该了解业务逻辑,它应该只负责和数据库打交道,所以,这个时候很难做。最好的就是在service中增加一个访问该dao的方法。(抛砖...)
我想遵循这些约束,会让你的系统看起来非常清晰,易于扩展和维护。

Anonymous said...

you have a fast hosting