本篇文章主要分析，架构师在设计系统架构时，应关心哪些关键要素？
一 业务场景
A公司是一家服装公司，主要提供服装一体化服务(服装设计，服装销售，售后服务等)，该公司主要通过淘宝，天猫，京东等平台进行销售，由于公司
良好的服装质量，高效的服务水平和良好的信誉等，使得公司的销售量不断地增长，到了第五年，公司的销售呈现指数型增长....，为了迎合指数型的业务需
求，公司高层决定使用互联网技术来迎合指数型的业务需求。
该项目由CTO全程负责，并向CEO汇报，CTO指定小张为该项目业务负责人，小红为该项目技术负责人，他们两人定期向CTO汇报。其中，CTO主要负
责系统的系统架构，项目管理，团队组建，关键业务沟通等工作，小张主要负责业务相关的事，如需求调研，需求文档编写等，小红主要负责项目落地开发，
如核心模块开发，及时解决团队开发出现的技术性问题。
如此，CTO做出了如下的业务架构，该项目命名为：线上仓储系统（OnlineWMS）
（1）通过线上平台提供的接口，抓取用户订单
（2）将抓取的订单存储到仓储系统
（3）将订单相关信息传递给SAP(可以理解为财务系统)
（4）当货物发送后，在WMS系统上，通过物流接口查询订单状态(发送，未发送，已收货，退货等)
二 架构师应关心的若干要素
1.明确系统功能(what)
在业务架构中，系统架构师一定要非常了解且明确系统要解决的核心业务，在设计前，建议考虑如下问题：
项目需求是什么？
项目需求是基于什么背景下提出的？
项目需求的核心业务是什么？
项目需求的难点和痛点是什么？
....
在充分考虑如上问题后，就是问题答案的寻找和求证过程：
答案寻找？
如上系列问题，均可在需求文档中找到，因为一般情况，需求文档都会有详细描述，需求文档的来源一般经过几个阶段：
需求提出=》需求调研=》需求初稿=》需求评审=》需求修改=》需求定稿
答案求证？
系统架构师在充分研读需求文档后，对需求基本有所了解，然而这些所谓的了解，是需要与需求提出者，需求撰写者等关键人物确认的
确认的，这个过程也叫答案的求证过程，只有该过程确定后，方可进行下一环节。
2.定义系统边界(Scope)
在充分明确需求后，就要定义系统边界了，首先来了解一下，什么叫系统边界。
系统边界：指本次项目由哪些系统构成(或子系统构成)。
CTO为OnlineWMS系统定义了四个边界：线上接口(订单的来源)，物流接口(订单状态查询)，WMS系统(订单管理，衣物存储等)，SAP系统
（财务相关）
很容易看出，这几个边界定义还是比较明显的，职责分工明确，无重叠业务。
3.定义系统之间的交互方式
CTO为OnlineWMS系统定义了四个边界，且这四个边界的交互方式是以接口的方式进行的。
4.接口设计规范
关于接口设计规范，请参考我的另一篇文章 如何设计一个良好的接口
5.系统难点
该系统，从线上抓单，且将订单及时地存储到WMS系统是一大难点和挑战点，尤其在双十一，双十二等高峰时段，成千上万的高并发量，
10w-1000w的订单量等都完全有可能导致系统崩溃。然而，该难点却有很多可以捕捉的特点，归结如下：
（1）存在高并发量特征
（2）存在大规模订单特征
（3）存在系统响应及时特征
（4）存在高并发、大规模订单集中于某个时间段，而非长时间(如1年)特征
.......
6.业务模块与非业务模块拆分
该系统中，存在业务模块与非业务模块，需要进行拆分，如非业务模块授权管理、日志记录等需要从业务中拆分开发来，可以采用AOP技术
实现，如Spring AOP,AspectJ等。
7.模块解耦
该系统中，模块之间存在必要的依赖关系，为了尽可能的降低这些依赖关系，可以采用DI(依赖注入技术)来解决，如Spring框的DI。
8.技术选型
涉及到前端框架，后端框架，ORM框架等。
在选择框架时，尽量选择主流且被广泛使用的框架，尽量不要选择不太主流或太新的框架。
在框架组合时，防止过大，也防止过小，如SSH,SSM,SpringBoot+SpringCloud+Redis+Mongo+MQ+Dubbo等，要根据具体的业务场景来选择。
9.开发团队
在组建团队时，要充分考虑风险，如团队人员突然离职造成项目延误等风险，建议采用职能组织架构结构来组建团队。如一个技术开发经理，2个高级开发，3个中级，4个初级等，
这样搭配的好处是，当技术开发经理突然离职(一般技术开发经理很少离职)，2个高级开发可以顶替上去；若有一个高级开发离职，两个中级可以顶替上去....如此，就算某个人离职，
对项目影响都不会太大。
10.项目管控
管理项目计划，项目进度，开发团队人员情绪、处理开发技术问题等。
三 版权区
- 转载博客，必须注明博客出处
- 博主网址：http://www.cnblogs.com/wangjiming/
- 如您有新想法，欢迎提出，邮箱：[email protected]