Java开发网 - Re:Java软件架构设计慨论(转载)--设计模式和系统架构的关系

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者

Re:Java软件架构设计慨论(转载)--设计模式和系统架构的关系 [Re:九佰]

floater

Java Jedi

总版主

发贴: 3233
积分: 421

于 2006-03-29 12:21

A software system can be divided into different components according to its functionalities. Though there are many ways to divide a system, the business functionalities are central to the entire system, and thus is a more appropriate way to divide the system (so we have the term - domian driven design, or DDD in short). Each component is more or less self contained and independent(high cohesive and loosely couple, in fancy terms), e.g., we don't want to insert, update, and delete methods for a same single object in seperate components, and we don't want to mix UI and DAO classes in one component unless there is nothing else and the size of the system is very small(and it could grow really large).

Depends on the size of the system, each component itself can be a large subsystem, and so on. Nonetheless, we always try to recursely divide a large system to smaller components so that the smallest components can be handle d by teams of size 8-12 folks(a managable size of a team), or even just one person. So eventually, we convert the communications between components to team communications.

These smallest, managable components are the pivoting points in the entire system because they largely divide the design and implementation. Consequently, their interfaces and above belong to system design, which should be done before any lower implementations start. Because the system design is more relevent to business logic, there is really no room for saying in computer terms, like framework, design patterns. So I call the commnunications at this level "businessman's talk". *A good system design should let us seperate system concerns and application concerns, and further, let us hide the system concerns*. This is the principle that we should follow at this level. For example, Spring has two ejb access factory beans(local/remote) such that we can use them to inject service interfaces to other classes, rather than expose the JNDI lookup. This enable us to use other component services without caring how to get them, so when components communicate with each other, they can just call each other in business manners. Similarly, Spring provides other expose/lookup methods for RMI, HTTP, etc, convenient factory beans. Sometimes, Spring is not enough and we have to write our own classes, and we should follow the same principle as mentioned above.

On the other hand, the implementations for the smallest components can't hide the system concern, instead they should isolate these concerns and make good use of them. This is where the design patterns are used, they are used to design technical implementations, not for business talks. For example, caching is really a system concern, your system should be able to run with or without caches. A better design of the implementation is write a version without caching, then use a decorator pattern or AOP on top of that. Spring MVC is a nice web frameworks, they let us treat some of the common concerns as a system concern, e.g., the view pages can be jsp, vm, fm, so that we can swap out to a different implementation. So at this implementation level, we fix the component interfaces and throw all our energy to make the implementation better, with all the tools we can find.

Even this is largely at the implementation level, we still need designs at this level because it could contains tens or hundreds of classes. The difference between this level and the system design is that we have to consider both business and system concerns.

Finally, everything is relative. The divider between the system design and implementation can shift overtime when complexity changes. The divider between application concerns and system concerns can change to. So constant cleanup/maintanence/refactoring is needed.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler, Refactoring - Improving the Design of Existing Code

话题树型展开

人气	标题	作者	字数	发贴时间
10393	Java软件架构设计慨论(转载)--设计模式和系统架构的关系	九佰	2137	2006-03-22 16:20
9512	Re:Java软件架构设计慨论(转载)--设计模式和系统架构的关系	floater	3780	2006-03-29 12:21

已读帖子

新的帖子

被删除的帖子