给朋友的信（之二）

朋友的来信：

====================分割线======================

客套的话就不说了，

客套的格式就算了。

直入主题：

     看了你的 简单之美，有几个感受：1, 书的价格不便宜，2，书的内容有价值。

    

    先说说我自己吧：跟你的经历差不多，从汇编到c，c到c++，再到java的世界。一路走来，也有些思考。

   

   自己的想法：

        曾思考如何把需求表述的很容易理解，能否像UML一样的方式，有RML来表达客户需求 。

        曾思考如何封装出更好的类，使其能简单并且能提供尽可能不依赖其他的数据。

        曾思考是封装API，还是做框架。

        曾思考架构是如何来应对变化的需求的。

  你是否能给点建议，和实例？

 

对书的几个遗留问题：

 1。在需求一章，孔如之给王蓉推荐了什么书（请告诉我书名），可以让王蓉接受，那么王蓉以前是如何做的？

 2。我对你将的隐喻还是一知半解，没有领会要义，能否在阐述一下？

 3。感觉书中对部属将的很少，提到性能问题，在解决性能问题上，架构起到什么作用？

 4。书中提到把业务映射成一个接口层，不太理解，我觉得理解成一个切面是否更合适？

 

我觉得自己在软件方面有点孔如之的半个影子。

不知道你是什么样的孔如之？

                                                   O(∩_∩)O哈哈~  能否有时间解惑答疑

我的回信：

===============分割线===============

很高兴能和你交流。
我试着提些建议和回答你的问题：）
1. 需求表述很重要，我不知道你提到的RML是怎么回事，我倾向于从粗到细多层次表述需求，在每一个层次上都做到完整。比方说，保险业务，最粗的表述可能是， 录单人员录入保单信息，录入后尝试承保，承保时检查自动核保条件，自动核保通过，系统自动正式出单，自动核保不通过，系统自动发送给核保人员。核保人员修 改保单信息，然后尝试承保。。。看上去像是一个工作流程。实际会比这个复杂一些，但没有问题，要在这个层次上做到完整，然后再细化下去。在实际工作中，我 们看到的需求往往是粗细混杂在一起，很难在多个层面上有完整的故事。但是我没有充分地实践过需求分析工作。我的理解来自于我对设计的认识。设计也是个从粗 到细多层次表述的过程。我随信附了一个ppt，是今年11月底一次架构师沙龙上的讨论。也许可以帮助我表达自己的这个想法。

2. 我觉得在企业应用中，除了在类这个级别考虑封装（这通常是一些设计细节），更多地应该考虑在组件（一系列的类组成）级别进行封装。个人认为，要让一个类不依赖于其他类，不是一种好的想法，在组件级别考虑内聚性是比较靠谱的。

3. 框架是技术层面的，组件是业务层面的。我向来反对框架层面的API（除非它是标准），只有组件层面的API才是我们对业务领域的理解，而这些理解是一般企业应用软件开发组织的知识财富。

4. 应对需求变化，通常是框架和我们自己设计的程序结构的问题。后者更重要。

5. 那本书是我杜撰的:-P

6. 关于隐喻，可以参考那个PPT，里面有一些很好的例子

7. 对于性能，在架构设计时要始终关注，例如，Cache的使用，JDBC和Hibernate不能混用，如何控制对象的生命周期，如何减少数据库的访问等等。

8. 把业务映射成一个接口层，或者说切面，这可以结合SOA和BPM来理解。

我身高只有一米六几，性格比较和谐迁就，做事方面原则性也比较差（总是希望能有改变），总之，身上没有多少孔如之的影子。我只是希望看到有很多的孔如之，我很尊重“孔如之”这种类型的人。

不敢说答疑解惑，大家一起讨论吧。最后，谢谢你对《简单之美》的评价。:-）。