架构 理论 软件过程 错误认识 总结

架构在软件过程中的什么时候出现

1.1最常见出现的概要设计之前，偏技术架构。

1.2在做需求时候也会写业务架构。

1.3在最前面出方案的时候会出现架构相关内容。

架构在软件中到底作用是什么？

很多人说架构是为解耦合，扩展性，强壮性，鲁棒性，但是其实这些都为了系统性能需求。

大家想想软件重构，软件架构在一个公司历程中什么时候被重视起来？不是在公司产品被大量使用时候。

高德纳Knuth 定律

“在(至少大部分)编程中，过早优化是万恶之源” 
高德纳被称为“人工智能之父”，这条定律是高德纳(Donald Knuth) 的经典语录之一，它告诫我们不要过早优化应用程序中的代码，直到必须优化时再优化。 
的确，简单易读的源码可以满足 99% 的性能需要，并能提高应用的可维护性。最开始使用简单的解决方案也让后期性能出现问题时更容易迭代和改进。

架构在软件过程中做什么用？

首先说一下软件开发过程，不管是敏捷开发，还是老的瀑布式，都是业务-》需求-》开发。现在做服务化比较多。各种中心，各种微服务，有人就提出了先简单了解需求，然后马上定义接口也就是服务，然后再适应业务，数据-》接口-》业务。因为归根到底最后都是对数据模型的添加，删除，修改，查询。这样做的好处是服务以后可以支持各种类型应用，比如Web,App,公众号，小程序。大公司都这样做。给大家举个例子。比如阿里的商品中心，阿里的商品都在一个大部门管理，不管对方要什么样子的数据，直接调用就好了。不可否认，这种方案定义服务供调用方使用很适合阿里。但是我想说的，阿里这种商品中心的建设是经历了很长的一个过程，一个业务领域模型确立的过程，如果是个新业务大家不要采用这种方案。因为你并不知道怎么拆分这些业务模型合理。本身拆分这些业务模型是需要一个过程的。一个学习，取舍的过程。其实要达到一个接口适应Web,App,公众号，小程序等的原因不是你的接口定义得有多好，多泛化多抽象。而是本身你Web，App，公众号做的都是一个业务。比如电商的网站，电商的App,电商的小程序，公众号都是卖东西，没做其他的。所以你在根据web需求开发的接口适合，App。业务变了就要修改接口。有一种接口开放平台做的很泛化很抽象原因很简单，就是接口得变化影响很多问题，对大众的接口，改一点人家老的调用都报错，这可怎么行？所以要做的很泛化很抽象。也不可否认有公司直接就上中心，那你没有看到这个公司的头们都是这个行业的专家吗？归根结底一句话，别人能玩的，你不一定能玩的起，看实力的。

还有一个问题就是Web和App的接口服务有什么区别？

区别很简单，你想想Web用什么写代码，js+css+H5,App比如安卓是java，语言区别造成H5处理数据就比较困难，java就比较简单。所以App你让他自己处理数据可以，接口可以比较多，比较细，但是js处理数据就比较麻烦了，最好后台接口可以一步到位。举个例子，你怎么不用c去写信息系统，java火起来也是因为j2ee他封装了好多企业信息化的模型。

有一种说法是不行就把数据全部给前端？

这个说法是不靠谱的，不如你把所有订单给前端，包括已支付未支付，但是你有没有想过，你怎么分页？接口得稳定是取决于业务的稳定，领域模型的稳定，所以一个公司业务稳定才是对的，也才是有利于企业发展的，否则东一下西一下，这个没做好就去做下个app，怎么可能有持续发展。很多电商的订单不就是那几种查看已支付，未支付，配送中什么的。所以为什么不直接写能满足这四个状态的接口。

有一种说法是手机如安卓端是java这种高级语言写的，那么把一点点业务逻辑写在前端也没问题？

这个说法针对微服务是没问题的，但是你写的是大而粗的接口，那就算了吧。那就出现上面提到的问题，你这个接口想复用在微信公众号，微信小程序呀，由于有点业务逻辑竟然在前端，你接口就不得不修改了，要不微信小程序前端也得写一点业务逻辑，这不是重复了。

最后总结业务稳定，业务领域模型拆分好，定义好边界，范围。才是后端接口服务稳定的前提。