从架构师的角度去看如何去写代码：从刚开始重写代码，推翻原有架构，从新设计等等说法，来讲明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并非架构进化的事情，而是我的对问题领域的逐渐深刻理解的过程。以上只是针对单一的Service部署单元的分析，扩展开去，对于其余的部署单元也是相似的。每一个单元的下一级均可以认为是Repository，每一个单元的上一级均可以认为是User。这些实践在我本身的项目中都有用到，很是的有效，迭代的速度很是的快。不少人担忧Business Model建很差，其实不要紧，刚开始能够粗糙一点，后续能够慢慢的完善。这个架构已经隔离好了每一个部分的变化对其余部分的影响，变化成本都在可控的范围以内。架构
当咱们有了好的架构，那就须要考虑如何将架构落地，而这个时候，代码就显得无比重要了！千万不要让代码成为架构扩展的瓶颈。工具
软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终仍是由代码的架构来决定。由于代码架构不合理，是没法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就很是的有限，整个系统最终很难长的更大。学习
因此咱们常常会据说，重写代码，推翻原有架构，从新设计等等说法，来讲明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并非架构进化的事情，而是我的对问题领域的逐渐深刻理解的过程。因此有必要再讨论一下，代码的架构应该是怎样的。设计
架构师和技术对象
不少人会问，特别是作软件行业的，架构师是否是须要学习技术，甚至是学习语言？ 若是一个架构师还有这个困扰—就如问这个问题的人，说明目前还不具有作架构师的能力，或者说还不具有对本身领域–哪怕是技术领域–的自信，更别谈业务领域了。部署
由于技术和语言，都是用来识别和解决所服务的主体的权责，保护并提高所服务的主体的权利的。特别对于软件领域来讲，必须明白软件自己是怎么回事，解决什么问题，还要解决软件所服务的对象的领域自己是怎么回事，解决什么问题，这就要求更高了。语言和技术应该是随手拈来才对，对于架构师这些都是工具。学习技术和语言，若是明白了这些技术和语言要解决的是谁的问题，什么问题，学起来是很是快，很是容易的。it
一样，采用哪一个技术或者语言，只要某个技术或语言所解决的问题的主体，以及所解决的问题，和本身所面对的问题的主体和这个主体要解决的问题，这二者是匹配的，那么这个方案是成本是最低的，所采用的技术或者语言就是靠谱的。没有趁手的工具或语言的状况下，本身设计一个也不难，由于很清楚本身要什么。要不要本身作，无非是一个成本问题，也就是利益问题。而且从这个思路下去，选择的工具和语言确定都是最简单的，成本是最低的。由于架构毕竟解决的仍是人的利益问题，成本越低越好，这个成本固然是长期整体成本，不是眼前的短时间成本。扩展