Sorry I have to type in ENGLISH.

Just now I viewed a news from outside mainland. More than 20 persons were shot by armed polices in Dong zhou village in Shan wei. The news was proved by Xinhuashe. You can find it by Goooooogle.

What a damned gvnmnt!

社会的中坚力量永远是那些大多数人群，尽管他们收入极低。在美国，中产阶级是社会的中坚，也是因为人家人数足够多。

政策总是不公平的，这也是因为社会的层次划分。美国的政策不是也偏向中产阶级吗？可是像我们从小就热爱的祖国（省略。。。），这样把政策严重偏向少数人群的，还真是不多见！尤其在这所谓的世界大同，地球村。。。的时代。

我们越来越喜欢YY，因为不用负责任。这也是网络上玄幻、奇幻、架空历史。。。所有与当前社会、生活无关的小说风行的根源。

@Vincent Zhao

Maybe you have seen too more AVs.

@weide

Oh, Either you misleaded me or I miunderstanded you.

Forget it. I think the platform choice mainly depends on the system scale. Of couse you should think about other issues. As I know (from friends), there's no successful Enterprise Level system (I mean very large scale) on .net platform. Try to identify your system scales:

1. Is it a information collecting/organizing/OLAP system?
2. Are you preparing to use Workflow in the coming system?
3. Do you have any complex business process?
4. Is it a real distributed system?
5. Are the customers mature with IT, could they make full/less use of IT technology to help themselves?

First of all, you should try to manage system change, then complexity. Also find out what design level you are in may help you to do better.

Besides, environment influence may not be ignored and should be pay more attention to.

基本上每个公司都是这样的。这是一种行业现象，可以用一句话来总结：
做，是死，不做，也是死，所以：“死，就一起死！”
最终受伤害的是谁呢？

@临海观潮

Excellent perspective. I thought about it but forgot to wrote them down. Many cases, when you finished a system, you may find that marketing was more important than what you thought before. Since it do act an important role while developing, you should think about it, at least ask someone to do that.

Glad to see your awesome work. :)

Personaly, I think your article put too much energy on technical matter. But actually far from what you want. Maybe you should focus on Enterprise Application Integration than technology choice.

From now, I can't see which tech is more suitable to your situation. Please check your problem and your purpose. I don't think they are corresponding to each other.

Legacy apps mostly did not use component technology, thus you must think about to integrate them on persistence level. while you want them to be used continuiously, you should think of collecting information to build a publishing system, unless you are ready to replace them, do not focus on concrete technology/platform by now.

编辑的时候使用“高级选项”，可以选择只显示摘要。

节哀！愿他在天堂中永生！

好文啊，受教了。

@WideWeide

passed.

我算是不懂XP，一家之言，仅供参考。^_^

Excellent work!
就知道你一直在关注关于架构的讨论，现在终于看到大师出手了！^_^

真高兴讨论越来越热烈了，真理越辩越明，在这脑力的震荡中，让我们共同进步吧！

发现笨笨这个图不错，不过“公司高层主管关注中长期利益”在国内基本是不存在的。很多公司的高层根本就没有中长期利益的概念，典型的小农经济思想，短视，见利忘义，急功近利，唯利是图。。。可叹我们的软件产业就构建在这样的基础之上！！！

我认为：
设计做的不够好+成员个人能力较好+Refactoring=XP
设计做的不够好+成员个人能力较差+不+Refactoring都等于没有设计过程的开发=一团乱麻/大小取决于项目的规模。

@dove

As you know, 关于Martin Fowler是朋友说的。

Anders和Martin应该是殊途同归：Technology makes life easier. 无论是Code Guru还是Architect，如果不能做到这一点就是失败的。Anders和Martin都做到了这一点，无论他们谁高谁低。

我的真正的观点是，选择什么都是可以的，但别忘了我们的最终目标。

@笨笨
交换个链接先。

看到了没，这里也有自称高手的呢，我自称预备役架构师也是学来的。^_^

@笨笨

在征得你的同意后，已经加了。呵呵。你这几篇写的很好，可以发到ARCHITECTS里面。在编辑随笔时有一个选项，勾了就可以了。

@锅炉

真幸福啊，还有1/3时间可以发呆。

GOD HELP HIM!
让我想起了那个只扔了一只靴子的笑话。

看过了，给了点意见，希望你能喜欢。^_^

写的很有思想，提一点意见：
PAGE 7:
J2EE 运行时的层次，建议参考SUN的ARCHITECTURE CUBE：
水平的是LAYER:就是你的上三层+SPPSERVER+JVM+OS+HARDWARE
垂直的是TIER:THIN/RICH CLIENT | BUSINESS LOGIC | PERSISTENCE.....
从外到内的：CAPACITY, SCALABILITY, SECURITY.......
PAGE 8:
参考HVM PATTERN: HORIZONTAL VERTICAL METADATA你就是这个模式了。
PAGE 9:
工具和产品，参考Richard Hubert的Convergent Architecture和OrganizationProcessResource元模型。
PAGE 13:
建议架构和产品发行达到高度的一致性。

整个PPT很有启发性！收藏了！

AGAIN, WOULD YOU LIKE TO ATTEND ARCHITECTS?

啊，我没有看。现在看看，学习一下。

@锅炉
totodo说的对，不过这话应该放在你这儿：
“呵呵，可惜不做系统管理，不然爽死。。 ”

比起来白衣的菜多了，虽然比我们的好。

笨笨写的很好啊！
“主要做法是喷”是什么意思？

PS:很高兴看到大家都关注和讨论软件架构。

@锅炉
好象HP质量很差哦。

按照你前面说的，你自己应该成为瓶颈了吧？我认为XP对个人能力要求比较高，你这样的团队不大适合XP。

@romza
这个没有一个标准。我自己认为还没有达标（自己的标准），或许别人看来我达标了（别人的标准）。无所谓，你不妨认为“我根本就是个XXX。”另外，我搞个“架构师之家”其实也没有自称“架构师”。：）上次和朋友交换链接我都要他给个“预备YI架构师”的TITLE。这么看来我还有点自知之明吧。搞这个东西只是说明一件事：“我有钱就可以开公司，不懂管理无所谓，我可以请职业经理人。”

@wfeng007
最后一段是引用Donald的。

@wfeng007
passed.

好啊，Donald的建议很好。

没有办法，象你这样已经拍过3部A片的大影星是不会理解我们这种小人物的苦处的~~~

不客气，下载个DSM的小软件，会有帮助的。

最新消息，又看不到了。

接口依赖造成的瓶颈现象

可通过DSM（设计结构矩阵）得到TSM（任务结构矩阵），这样优先级明确，可以有一定的帮助。

写的比较匆忙，如果有错误，还请大家指正。

可能还不够详细吧，但是哪里胡说八道了？拜托，如果有错误请明确指出好不好？

david.turing，passed.

早晨看了一下可以了，可是回了一个评论后又看不到了，怎么回事？

“不就是改几个页面嘛”

客户完全可以这样说。因为他们不懂技术，也不能要求他们懂的技术。在修改请求合理的前提下，开发人员有责任向客户说明为什么修改工作量巨大，至少要达到认识上的统一。如果无法说明，则软件质量多半有问题（可修改性？可扩展性？）。无法说服客户吗？客户并不都是不讲道理的，尤其做久了，比较熟的客户，完全可以说服的。

大家都知道中国的官本位，政府如何如何。但这能成为我们推卸责任的理由吗？

在客户基础好的情况下还是可能实现的。关键是客户基础好的时候，你已经一堆垃圾了，是重做，还是凑合？不过不管怎么样，这是我们努力的目标吧。

爽什么啊，我们花钱，你挣钱啊！而且这次被偷，真是亏大了。

握个手，我也这样用的。

很有感觉！也许是刚刚看了thekll的《香山》的原因，有一些伤感。

To canonical:

工作几年之后的IT技术人员，对于未来的职业规划，无非技术路线和非技术路线两条。在中国能够坚持走技术路线的人不多，也愈加艰难。但人总要有点理想，或者简单说要有点想法吧。这也是一个小圈子，我希望它能够成为家，成为起点和终点。

欢迎！你已加入架构师之家。

我觉得MDA做为一种思想已经算是深入人心了。我是一个局外人，不知道MDA最终的目的是什么，如果说是完全的自动化，我觉得是一件不可能的事情。让我感到最为迷惑的是，对于MDAer来说，到底是M修饰A呢，还是A修饰M？

有道理！有没有兴趣加入“架构师之家”啊？

笨笨，有没有兴趣加入“架构师之家”啊？

到电脑城装机啊，不然要误工了。

内存也拿了，我没有写上。

哦，你搞错了，“摘要(只能使用字母、数字)”，应该是“EntityName(只能使用字母、数字和下划线)”。

Happy birthday to you and wish you have a nice day! Enjoy yourself!