顿悟, 软件的设计

这个说法很有道理

一个项目确实需要行业专家, 但一定不是项目经理, 项目经理应该是个多面手, 懂客户, 懂需求, 懂技术, 懂关系. 在真的项目中, 不仅要有行业专家(建模), 还要有系统系统师(偏软)和系统架架师(偏硬), 还有的群小兵,项目经理就是粘合剂.

呵呵, 是五笔, 以后注意.

3年左右的经验吧 跟过3个项目。

领悟的东西就是: 用户变更无处不在。

作为设计人员必须的要求：

1.各种模式一定要熟练，不是说模式是万能药，但是模式至少可以未雨绸缪的提前给变更找好台阶下。
2.责任心。 重中之重，客户可以不专心和你讲业务，但是系统架构者必须事无巨细的了解业务。 责任心三字说白了是职业素养。否则程序员会在背后骂你娘的。

以XP的观点,呵呵最近对XP有点上瘾, 以XP的观点,不用预设太多模式,好的模式会在渐进式重构中自动浮现出来

有句话是这样子说的，分析和设计就是：do right thing 和 do thing right.
这句话很短但是很经典。
所谓的分析这里就是说在领域中寻找到相关的问题域的内容（business或者domain），这个理论上来讲也可以认为是一个建模的过程。
而设计呢？其实他从整个软件过程来看，其实已经是属于实现级别的事情了，也就是对问题域给出的解域。
设计现在分的比较细的话，有架构设计（overall）和具体的软件设计(concrete),架构设计自然是架构师来做的，那么具体的程序设计可能就是由程序设计师来做的，这里可以看到分工的侧重点，架构师掌控整个项目的问题，而设计师在具体的某一部分下功夫。
那么为什么要设计？或者反过来说不做设计又会有什么结果？其实设计就是为了解决现实世界中（问题域）的复杂度，因为我们的软件总是只能模拟现实世界，无法真正替换现实世界，要尽可能地贴近真实世界的首要问题就是如何面对复杂度。比较常规的做法就是分而治之，那么在这里设计的价值就体现出来了，如何分？这就是设计，也就是do thing right.
就像说你要去一个地方，我们都知道走直线是最近的方案，那么这就是一个设计（这就是do thing right），如果你偏要走个三角形虽然也能达到结果但是时间无疑就多了，可是在真实情况下是不是一定能走直线呢？不一定要根据具体的情况来判断，而且会从多个方面来影响你的最终决定，比如花费，为了节约时间你可以“打飞的”，但是成本是不是高了点，虽然时间最短，但是可能你会选坐汽车，这这个角度来说，做设计其实是在多个影响因素中做balance。比如分层架构是不错给你带来很多好处，但是你是否就可以随意多分几个层呢？层太多是否会影响你的效率和开发模式？这些都是balance的因素，也就是说他会影响你的设计。
设计模式是什么也就是说我们面对复杂度的时候有很多已经形成固定习惯的几种解决方案这就是设计模式。低耦合高内聚其实也是面对复杂度的一种模式，所以做设计就是对复杂度的一种分解方案，分解得越好那么软件就越灵活越健壮。
不管是低耦合高内聚还是分层架构还是设计模式解决其实都是分解复杂度的过程中的一些被人们总结出来的套路。

因为这丫根本不知道什么是domain model。相反在ror兴起前java方面对domain model的实践普遍不如ror。

说的都不错，但你究竟要表达什么？

呵呵，同感！

顿悟过后，该干啥还得干啥