1、我们为什么总喜欢讨论技术，而不是业务？
作为开发人员，我们平常讨论比较多的是技术层面的东西，比如 Spring 框架、Redis 缓存、MySQL 数据库等等，我们喜欢讨论这些，是因为纯技术的东西比较通用，和业务相关性不大，沟通起来比较方便。
但你要知道，一个项目能否成功落地，首先需要的是把业务分析做到位，至于选用什么技术来实现，这是我们第二位才去考虑的因素。从架构角度看，业务架构是源头，然后才是技术架构。
2、分清哪些是基础，哪些是多变，架构就成了。
需要总体上理解业务，才能定义好哪些是基础业务，哪些是上层应用。
架构是逐步演进的，一开始自上而下直接搭建，怎么快怎么来。
后面业务复杂了，就要考虑如何拆分组合，哪些属于稳定的基础业务，哪些属于快变的上层应用。
不能指望一开始就构建基础平台。
筑巢引凤，这不大可行。
3、谈系统的扩展性一般都是在谈什么？
对于业务架构的可扩展性来说，系统如何能够做到柔性可扩展，是衡量一个系统架构设计好坏的金标准。
什么是业务系统，说的简单一些业务系统就等于模块 关系。模块拆分好了，关系梳理好了，往往一个业务系统架构也就定义清楚了。但是一个业务系统好不好还有一个非常关键的指标，那就是：系统的可扩展性和功能的复用性是不是很好，因为这关系到了整个系统的生命周期。
系统的可扩展性好，本质上是系统中各个模块的依赖关系清楚，系统中的各个模块不是复杂和混乱的，而是模块和模块之间关系清楚，很少有相互调用，很少有双向调用。
系统的复用性好，本质上系统的逻辑划分清楚，功能模块能够做到粒度适中，通用功能能够合理整合，给各个业务功能提供调用。
问：又看了一遍 如何提高代码的扩展性 的分享，里面提到你们团队会做概要设计。能分享一下概要设计抓的点是哪些吗？需要产出哪些方面的文档？
接口层
用户接口层负责向用户显示信息和解释用户操作，这里的用户可能是：真实的用户、程序、自动化测试和批处理脚本等等
领域层
领域层的作用是实现核心业务逻辑，通过各种校验手段保证业务的正确性，领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。（功能核心能力，供接口层调用）
数据层
列出MySQL数据结构的变化，DDL语句
4、如何支持系统的可扩展？
要支持系统的扩展，架构设计上必须能够控制系统的复杂度，面对新需求，要让系统复杂度做加法而不是乘法，从而保证系统的调整是局部化和最小化的。
所以，业务架构扩展性的本质是：通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。
那如何打造一个合理的模块体系呢？
具体的架构手段就是按照业务对系统进行拆分和整合：通过拆分，实现模块划分；通过整合，优化模块依赖关系。
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
