1. 软件架构设计可以基于数据库的模型设计也可以基于领域模型设计。对于业务系统来说，如果他的核心是数据处理和分析，而且数据量很大可以在架构设计时采用基于数据库建模的方式，对于一些中小型的应系统一般习惯上是用领域驱动设计。
2.分层是软件架构的基本理论。任何软件在逻辑上都可以分层，也可以适当的映射到物理层次上，至于怎么分，分多少层，要不要分等要看你的软件领域（每个领域都有一些现成的架构模式可以参考，所谓领域架构），在拿到需求的时候我们习惯上进行水平和垂直的分割，其实分层技术也是一种基本的架构模式。
3.bi商务智能，所谓的智能只不过是数据对业务的支持，通过etl对数据的提取，筛选与清理等动作，集合数据支持，通过分析报表，olap等等提供商业决策支持，其实bi只是业务系统的一种，只是在原有业务管理系统的数据基础上做了层分析模型，维度模型，更有利于商业决策罢了！
4.上班也已经有两三个星期了，每天都在坐公交车，从起点到终点，很无味。今天发现一个有趣的事，做公交这一途中发现了很多有特色的建筑，以前没注意。其实我们软件开发何尝不是如此，需求就像路景考察，你不可能在一次起点到终点的过程就看到所有的建筑，你必须在公车的不同角度去看，很多建筑、路途景色会让你眼前一亮。需求在起初的讨论中是很难澄清的，除非你是非常小的系统。必须在不断的开发中去探索，去发现和变更，现在很多程序员抱怨因需求和设计的变化而修改程序。其实这种现象很正常。
5.有时候可能凭着自己的性格，有离职的想法。但，当你静下心来想想，很多因素组织了你的想法。其实应该以一种平常心去面对发生了和将要发生的事。
6.五年前开始用 uml2.0，支持工具 rose 和 together 之类的。但是常常令人思考的是 uml 在项目中真的起到指导作用了吗？未必，笔者做的很多项目都是前期画画，后期抛弃。结果前期花费了很多时间拖延了项目的进度，而且在后期维护阶段，这些所谓的图也没有为后来者做什么贡献。就是我所在的h公司，在这方面也不是很理想，或者说是一团乱麻。我想一个很重要的原因就是很多人会用uml，熟悉几个工具，但uml的精髓并没学到。还有就是在项目组中没有一个体系结构师做这方面的工作，你可以说这是中国的大环境。不尽然，一直以来我个人都倡导体系架构。我们都知道 ap---适合小型项目、精英团队的开发过程，在体系架构方面没有严格的要求，所以不适合大型，团队分散的项目。前一段时间也思考了这个问题，写了篇论文 <<敏捷与架构对齐>>，下面我们还是认认真真看看uml的基本知识吧，为新手也为老手，有兴趣的可以看看，总结的还是可以的。有啥问题欢迎讨论。
7.项目客户端完全采用 ext 框架，表示层没有 html, jsp 之类的东东，只有 css和js。ext 是个很好的东西，也有一些 bug，不过他更新的很快，也有很多示例系统和组件。在构建前端表示的时候可以在很短的时间内作出很炫的效果，真的是令你眼前一亮。和后端服务交互完全是基于 http 协议的 json 对象字符串，可能有的项目中这是一个折中的选择。不过我们现在这么做确实使服务端和前台表示端完全分离了，结构很清晰，而且也有明显的效果。对于后台开发也是严格遵守分层概念，符合正交体系结构的设计概念，基于线索的开发模式和分工策略。在体系结构方面有一清晰的架构视图，反映多中关注。目前这个项目已经接近尾声。第一个小版本要发布了，期待。
8.源代码就是设计，似乎是老生常谈，但是很多人还是转不过弯来，俗话说：“重构一段代码很容易，但重构一个人的思想是很难的”。
9.对于一个分层的系统来说，代码构造方式有两种：一种是自顶向下的构造方法；一种是自底向上的构造方法。这两种构造方法都来源于分析，也就是说分析也有两种：一种自顶向下的分析；一种自底向上的分析。这两种分析都源于系统的逻辑层次性（如系统的层次理论，上层下层的关系（一种分析和分解关系）），系统分层源于复杂问题的分解，也就是所说的简单化问题空间以及问题归约方法论。这种分解方式源自于人们认识自然和改造自然的一个学习过程（是人们改造自然、认识自然的经验在系统开发中的一种体现）
10. 支撑系统参考架构
支撑系统架构
|
————————————
| |
静态架构 动态架构
| |
—————————— 业务场景架构
| |
应用软件架构 视图架构
|
————————————————————
| | | |
功能架构 技术架构 信息架构 流程架构
本博客为学习交流用，凡未注明引用的均为本人作品，转载请注明出处，如有凯发k8网页登录的版权问题请及时通知。由于博客时间仓促，错误之处敬请谅解，有任何意见可给我留言，愿共同学习进步。