在浏览了很多讨论设计模式和应用框架的论坛后，发现人们在该类版块主要讨论的东西有：
1、讨论某一具体设计模式。
某人刚学习设计模式不久，然后发布自己对某模式的理解，然后发贴请教高手如何应用该模式。
2、讨论应用框架。
人们热衷与比较各类应用框架，MVC，如讨论Spring, Struts等。比较他们的有缺点，互有支持者。
3、讨论应用框架使用中遇到的问题。
讨论这些框架的具体应用。请教如何解决在应用这些框架时遇到的问题。
人们讨论的问题都比较实际，主要目的还是为了解决实际的日常工作中的项目的问题，这很自然和可以理解。我想即使是设计模式、体系结构、应用框架的讨论社区，能常光顾的还是做编码这一层的人居多做系统分析和架构设计的人少，所以不难理解人们讨论的是以实际编码实际应用为主，而讨论模式采掘、体系结构设计和应用框架开发的几乎没有。
以上是一些理论基础。大部分是没有问题的，但有些是自己的理解，所以有不同意见的就赶紧吱一声啊，以便及时更正。
1、讨论如何更好的描述设计模式，讨论模式之间的关系，如何分类和组织模式，以让后来者系统的学习。
2、讨论模式语言，用多个模式的组合解决更大更复杂的问题。如何描述和分类组织模式语言。
3、讨论软件体系结构模式，提出某一应用领域的软件的体系结构的设计，并讨论如何描述和如何应用之。
4、讨论如何采掘模式，发现新的模式。在已开发的多个系统中采掘成功的设计经验，然后描述并提出。
5、讨论如何构建一个模式库。这个模式库应具有的功能，她如何分类描述各种模式，如何描述模式间的关系。
以上共有五点，其实，最终可归纳为一点，即第五点，前四点都是为第五点而服务的。模式库的研究也就是研究如何对设计模式，模式语言，体系结构模式的分类和描述，如何采掘新模式等等。本人想建立一个体系结构模式库和设计模式模式库，收集、分类、组织和索引模式。或让新手学习过来人的成功经验，或基于这些模式以及结合构件库系统形成半自动的大规模的基于复用开发的软件生产线。
之前我们讨论使用Composite+Visitor以及其他模式结合解决应用中经常碰到的树形结构访问这一课题，属于楼主提到的“模式语言”范畴：能解决某一问题的整套模式的集合，就是一个模式语言。
连接地址如下：
Composite模式和树形结构的讨论
很多人怀疑模式 而不怀疑数据结构，是因为模式没有成为软件基础教育的一部分，所以，深入了解模式的人比较少。
其实数据结构与模式语言的结合可以很好地 重用的解决一类通用问题，下面这个主题就是结合Composite+Visitor模式和二叉树概念解决树形结构通用问题访问这类实际应用中问题，从而形成解决一类问题的框架，这样不是提高我们开发效率和开发质量吗？
目前我们应用中，大量的是树形结构信息，如网站内容 Blog 论坛，商品信息 ERP分类 凡是涉及到树形分类都可以用这套模式语言来考虑，我只是举了一个例子。
关于对模式作用认识不是很清楚的几组讨论：
一个懂模式又咋样？不还是一个技工吗？
http://www.jdon.com/jive/thread.jsp?forum=91&thread=17831
也有人认为：
"通用的框架解决的是通用的问题，但不一定是最佳的解决方案。
做技术也是追求真理的一种方式，不必做某种技术的保皇派吧。
我相信技术方案只有最适合的，没有所谓最好的和最通用的。"
通用框架确实是解决通用问题，通过框架其实是通用模式语言的集合，具体解决方案还需要结合具体模式组合来解决。
其实坚持模式语言，是追求软件的高质量，追求软件的最大可扩展性和重要性，这本身是一种高质量的技术方案，它的采用与否只是由技术以外原因决定：时间和进度以及费用。
关于“我相信技术方案只有最适合的，没有所谓最好的和最通用的。”
技术方案是人做出来的，而模式构成的方案可以提供“没有最好 只有最合适的”实现方案，也就是说：只有使用模式才能真正实现最适合的方案，而不是每个人当事人自己觉得合适就合适了。
相关连接：
http://www.jdon.com/jive/thread.jsp?forum=121&thread=23654
该贴楼主提出的问题，如果从模式角度考虑而提出解决方案将是一个合适的技术方案，从该贴问题的解决方案争辩中，体现了三个不同方向：1.提出以模式架构提出的解决方案; 2.从产品或标准产品的角度提出解决方案；3.从底层多线程角度提出解决方案，而不是面向组件和面向构件基础的解决方案。
三种方案代表三种思维，说明我们现在对解决问题的思考方向还有分歧，那么要统一在以模式为基础的更高层次讨论是多么的难。
类似的组织和工作已经不少了～～ 楼主的计划有什么不同吗？
作为一个研究话题，“模式采掘”至少存在 10 年以上了。记得在什么地方看见过1996年一篇马里兰大学计算机系的文章，就在讨论模式采掘，描述和模式库。不幸的是，这个东西从来没有从“话题”上升成真正的“课题”。
包含模式库的 MDA 软件，比较有名的有 TOGETHER CONTROL CENTER，RATIONAL，ECLIPSE UML2正在向这个方向发展。楼主的计划是类似的么？
我想，我们有必要建立一个国人自己的中文模式库，其内容通过协作式写作而提供。每个模式社区的人员都可对模式库作出自己的贡献。把模式库建成一个共享的经验库，知识库，for the people, by the people.
我想，模式库主要需要解决的问题就是如何分类和描述模式问题，使得模式的组织结构清晰；提供方便的检索功能，让人们快速找到所需了解的模式；要能够利用Web和超链接的特性更好的表达和呈现模式及模式间的关系，让人们觉得浏览在线模式库比看静态组织的书本强；要提供简便易用的创造工具，让模式社区成员协作写作。
我想，从另外一个角度来看，模式库就是一本由大家努力，集大家智慧和经验于一体的一本在线模式书。这本书不断更正和更新，力保权威和正确；不断有人采掘新的模式并加入，力保完整和全面。权威和全面，我想这是我们的目标系统的主要特性。
不仅如此，关于“模式”的探讨，在本身就十分疲软的“软件工程”学科里，也不是一个受重视的研究方向。“模式”领域的定鼎之作 GOF，1995 年出版。试问，计算机界还有那个学科领域在用十年前的文物作教材？
WHY? WHY? WHY?
原因很简单，模式，或者“软件工程”的通病，软肋，遗传弱势：没有量化的研究语言，习惯和方法。
IEEE对“软件工程”一词的定义（没人指望我背出原话吧？），其中的关键词是“定量的方法和研究”。在科学和工程界，不用公式和数字说话的理论，是无法证明自己的（其实首先不能称其为理论）。这就是工程科学界的起跑线。这就是科学工程界对“理论”水平和意识的基本要求。
这并不是说模式无用。作为 经验抽象 和 实践指导 的模式有很大实用价值，本科教育应该涉及和介绍，虽然远远不应该，也不可能提到与数据结构和算法平级的地位。
归根结底，“模式”不可能成为科学，甚至工程方法论，原因首先在于“模式”对自身的定位：经验抽象、实践指导。 “模式”要成为 XX论 与数据结构、计算机语言、算法、操作系统。。。平起平坐，当务之急是重新定义自身的性质和目的。
如果“模式”，“框架”的演绎和努力方向，是一个可以数学（理论或者数值）证明其正确性、优越性的理论体系，并且成为一个软件设计的“正规方法 formal method”（而不是指导 guideline），那么它才有登堂入室的希望。
否则，“设计模式”就还是一本“高级技工入门指南”尔。不过你的工具是键盘而不是车床罢了。
我的问题是为什么需要“另一个”模式库。（Yet Another Pattern Library）仅仅因为它将是中文的？
还没有什么科技领域的东西因为这个原因而成功的。
> 我想，我们有必要建立一个国人自己的中文模式库，
个人认为，Ward Cunningham等人所创建的波特兰模式库更大的成功在于提出了协作式写作的概念(wiki)。因为既然是模式是经验，那就需要大众的参与，共享每个人的经验，才能达到更好的效果。然而就模式库角度而言，我不认为她是个好的模式库。那里似乎只是一些大牛们发布他们模式相关文章的地方。这些模式文章没有很好的分类组织，模式的表述风格各异。不仅如此，该网站的定位不断演变，历程如下：
http://c2.com/ppr/
1994年 模式社区及其他们的资源和应用；
1996年 普通设计、建筑以及方法；
1997年 从人和组织的角度看待规划设计；
1998年 偏激的规划设计；
2000年 维客本身；
2003年 维客、社会学等。
最后，这里更多的是讨论Wiki本身；还有由于Kent Beck的加入，这里又变成了讨论极限编程(eXtrem Programming)的权威网站。这就是现在的波特兰模式库。
此外，国外最大的模式团体山腰组(hillside)的模式目录，我想这里则正好与前者相反吧。然而，模式的分类描述还有必要进一步改进，才能吸引人们不再买书而上网在线学习模式，间接保护几棵大树。显然山腰组还是做得不够成功，以至没有改变人们的阅读习惯，还是有很多大树被砍掉来出版模式书籍。
还有一个很重要的一点就是，这些东西都是国外的，国人的E文水平你也知道，并不是很多人的E文水平都像我这样顶呱呱:-)。所以有必要弄一个中文的模式社区。而现有的中文模式社区就是我之前分析的现状，人们在论坛里讨论的东西层次也有待提高。
95年至今，已跨了一个世纪，已有十年之久。山腰组里的成员为模式研究做了巨大的贡献。不管她是个“话题”还是“课题”，我想做的就是推动国内模式社区在更高层次上讨论模式的相关“？题”。
你提到的支持模式的MDA软件，我暂时没有想得那么远。模式既然是他人的经验和智慧，人们只有学会了她才能运用好她的，不管你有多么傻瓜的工具支持。就像Rational Rose里的应用某某模式的那些向导,确实很方便，但是如果你连这个模式到底怎么回事都不知道，那么这个功能就成了摆设。所以，现阶段的模式库，主要的工作还是研究如何分类描述所有模式、揭示模式间的关系、支持模式库的自我演化、支持协作式创造，而由模式库直接支持软件系统的构造，这可放在下一步的工作当中。
我想需要有更多的人的想法来加入和实现语我们这个模式库当中。
对于dmuyy老师，我倒是感觉您自己做WIKI是不是有些难度，也许要是做cluster of WIKI会好一些。
我们先讨论一下模式分类吧。现在我知道的有如下一些分类方法：
1、按规模和抽象程度划分：
体系结构模式、设计模式、惯用法。
2、按解决的问题划分：
例如分布式系统、交互式系统、访问控制、通信、资源处理等问题。
3、1＋2，模式类别＋问题类别，形成一个二维的模式分类图式。
随着模式库中模式的不断增多，理解和使用模式库就越困难。一个好的模式分类方法，有助于人们更好的理解模式。好的模式分类图式需具有如下一些特性：
＋简单、易学，而不是复杂、难使用；
＋少而精的分类标准；
＋每个分类标准反应模式的自然属性；
＋根据该分类能让用户找到一组可能适用的模式，而不是找到唯一适用模式；
＋应对新模式的集成开发，而不需要对现有分类进行重构。
参考资料：
Frank Buschmann等，面向模式的软件体系结构 卷1：模式系统，译[M]，机械工业出版社，2003，211~214
至于现有的分类方法的优缺点，我不十分知道，需要大家一起研究；
至于现有的分类方法需改进点，我不十分清楚，需要大家一起讨论。
模式(名称,语境,问题,解决方案),这似乎是基本要素。除了以上的要素之外，可能还有别名，动态特性，变体，使用例子，使用后的效果等。对于模式的描述，有过于复杂和过于简单两个极端。如何做到对模式描述得足够清楚便于人们学习理解，又不用描述得太繁琐复杂？我们是不是可以讨论讨论呢？
对于体系结构模式，很多学者在研究一些形式化的描述语言，叫体系结构描述语言(ADL, Architecture Description Language)。他们提出了若干适用于特定领域的ADL。典型的有: C2 是一种基于构件和消息的ADL,适用于大型频繁交互的层次型图形用户界面的软件的体系结构描述; Darwin和 Wright分别将π演算和 CSP 作为其数学基础,适用于分布、并发类型的体系结构描述; ACME 是一种体系结构互换语言,支持从一种 ADL 向另一种 ADL 规格说明转换。其他比较有影响的 ADL,如 Aesop,Unicon,Rapide,SADL,MetaH,Weaves 等。
按照一定的描述方法,用体系结构描述语言对体系结构进行说明的结果则称为体系结构的表示,而将描述体系结构的过程称为体系结构构造。在体系结构描述方面, Kruchten 提出的“4+1”模型是当前软件体系结构描述的一个经典范例,该模型由逻辑视图、开发视图、过程视图和物理视图组成,并通过场景将这 4 个视图有机地结合起来,比较细致地描述了需求和体系结构之间的关系。
以上似乎表明，体系结构描述的研究欣欣向荣，形式一片大好。但我们可千万别乐观，事实上的情况是ADL 繁多,缺乏统一的 ADL 的支持。尽管 Shaw 等人提出了体系结构互换语言 ACME,但没有统一的体系结构描述语言框架与定义,不同体系结构描述语言所描述的体系结构规格说明难以互换。既然说没有统一的ADL，那么有人说采用业界普遍已认同的UML来描述吧。但我想毕竟UML并不是专门用于描述体系结构模式的，需要做很多扩展，用stereotype，这个过程中，势必又需要做许多标准化工作。
总之，在模式描述的路上，我们还有很长的路要走。同学们，我们赶紧起程吧，呵呵。
参考资料：
Frank Buschmann等，面向模式的软件体系结构 卷1：模式系统，译[M]，机械工业出版社，2003，211~214.
孙昌爱, 金茂忠, 刘超,软件体系结构研究综述,软件学报,2002,13(7):1228~1237.