.NET架构小技巧（6）——什么是好的架构
首先声明，可能本篇文章的含金量配不上这个标题，因为说起架构，可能大家都比较关注高大上的架构，比如分布式的，高并发的，低耦合的，易扩展的等等，本篇可能使你失望了，因为这些全没有，这篇博客的中心思想是——适合的架构，就是好的架构。
古时候谈婚论嫁，讲究“门当户对”，新时代是不接受这种“封建思想”的，如果我们把“门当户对”的意思，理解的更宽泛点，可能情况就不一样了，门当户对，不仅仅从经济，名誉上来理解，扩展到三观（世界观，人生观，价值观）上，是不是两个人，或两家人三观一致的话，是不是觉得就有道理了，有点哲学的意思了。言归正传，说架构。
相信有很多人遇到这样的用户，给我做个淘宝吧，或给我做个美团外卖吧，更多的是我要做个XX项目，和某某(大厂应用的名字)一样，这个时候，一般情况下大家都是心里在笑，笑什么呢？笑的人都心里清楚的很。对非行业里的人来说，难免。对于行业里的人来说，首先要了解做什么项目，为谁做项目，用户量是多少，访问量是多少，再就是项目预算是多少，工期是多长时间等等问题。要充分了解项目或系统的信息，其实这些信息都是对架构有影响的。
接下来分成两方面来看
外部——客户
客户要解决什么问题
客户系统的行业很关键，系统是偏计量统计，还是工作流程，还是费用相关，每个行业对软件的要求都不尽相同，难做的与钱打交道的软件，和容错率低的软件，对对开发者有更高，更严格的要求。
使用系统有多少用户
同时使用的用户数，这个是引导架构技术设计的主要因素。
开发工期有多少时间
时间有时会改变我们的架构的，有可能时间短，只能选最熟悉的架构，而不是最合适的架构，
客户有多少预算开发
这个更敏感了，这决定投入的人，时间，精力，最简单的，预算如果不充足，可能连架构师都不一样了，选一些能力，经验相对少的人来操刀。
内部——开发
技术人员
可调度的技术人员有多少，他们的专长技术是否满足你的架构，能否保证完整的在这项目的生命周期内。
系统需求交付概要情况
需求是否明确；交付是一次交付，还是边开发边交付
系统适合什么技术实现
宏观上要大体上有这个项目实现是什么架构：C/S，B/S，单体，微服务，前台应用，后台服务等
项目越大，影响架构的因素越多，这里只随想了几个方面，不足以覆盖全部场景，更适合的小项目，小团队参考，毕竟小项目的数量要远远大于大项目，同时小项目的质量，架构合适性要劣于大项目(可能关键在预算上吧)。
对于一个模块，一个项目，一个系统，要做到适合的架构，不仅要考虑技术，交付工期，还要客户资源，预期等方面，这样才能做出一个双方都共赢的产品，皆大欢喜。