部分理念说明
多租户
多租户（Multi
Tenancy/Tenant）是一种软件架构，其定义是：在一台服务器上运行单个应用实例，它为多个租户提供服务。
我司框架使用的是共享数据库、共享
Schema、共享数据表的数据设计架构，其中Magicodes.Admin支持分库。
DDD（领域驱动（Domain-Driven Design））
DDD是一种以领域为核心的设计和开发理念。DDD通过维护一个深度反应领域概念的模型，以及提供了可行的经过实践检验的大量模式来应对领域的复杂性。
领域驱动可以带来那些收获，主要有以下方面：
领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。
领域驱动设计尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。
领域驱动设计强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。
领域驱动设计强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。
领域驱动设计的思想、原则与模式有助于提高团队成员的面向对象设计能力与架构设计能力。
领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。
依赖注入
控制反转（Inversion of
Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency
Injection，简称DI），还有一种方式叫“依赖查找”（Dependency
Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。
RESTful（Representational State Transfer）
前面我们说了，有章可循，有据可依，有正确的产品流程和规范，我们的工作才不至于产生混乱，团队的工作才能更有成效。我们经常见到，程序开发可能只用了半个月，但是接口的联调却经常需要花费半个月甚至一个月左右。
如果API的设计更规范更合理，在很大程度上能够提高联调的效率，降低沟通成本。那么什么是好的API设计？这里我们不得不提到REST
API。
另外，REST
API的书籍很多，但是完整完善实践丰富的设计指导并不多见，我们有幸看到了微软团队的作品——Microsoft
REST API Guidelines，因此才有了此篇内容。
什么是REST API?
Rest不是一种协议，也不是一种文字格式，更不是一种开发框架，它是一种系列的设计约束的集合：无状态性、将超媒体作为应用状态的引擎，这个约束我们统称Fielding约束。也就是说，它是一种软件架构风格、设计风格。它的两大核心理念是资源和表述，这个能加快我们对它的理解，然而REST
– REpresentational State Transfer，英语的直译就是“表现层状态转移”。
简单的来说，在REST
API:URL定位资源，用HTTP动词（GET,POST,PUT,DELETE)描述操作。前面说了，REST
指的是一组架构约束条件和原则。那么满足这些约束条件和原则的应用程序或设计就是
RESTful。
为什么用REST API?
前后端分离主要以API为界做接洽的，这样就会有很多的API，API的表现力更强，更加便于理解。
REST API没有状态，不管前端是何种状态何种设备下都可以无差别的请求资源。
Restful API有直接的规范和原则。
简单的来说，有以下好处：
看到Url就知道可以拿到什么。
看到Http请求方法就知道要做什么。
看到Http状态码就知道干的怎么样了。
Microsoft REST API Guidelines
见：https://github.com/Microsoft/api-guidelines
单元测试
单元测试（unit
testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，C#里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
前后端分离
可以先参阅此文《Web
研发模式演变》：https://github.com/lifesinger/blog/issues/184
然后再回到下图：
前端工程化
前端工程化包含一系列规范和流程，其可提升前端工程师的工作效率，加快Web开发迭代速度，是现在前端开发领域中非常重要的一环。
DevOps
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
CI（持续集成(Continuous Integration)）
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
CD（持续交付(Continuous Delivery)）
持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
单一职责
单一职责原则（SRP：Single responsibility principle）又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特·C·马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的内聚性原则发展出的。
所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。
一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。
TDD（测试驱动开发（Test Driven Development））
TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。
测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。
TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。
微服务(Microservices Architecture)
微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
对于大型应用程序来说，增加更多的用户则意味着提供更大型的弹性计算云（EC2）实例规模，即便只是其中的一些功能扩大了规模亦是如此。其最终结果就是企业用户只需为支持超过微服务的那部分需求的EC2实例支付费用。
微服务应用的一个最大的优点是，它们往往比传统的应用程序更有效地利用计算资源。这是因为它们通过扩展组件来处理功能瓶颈问题。这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代。最终的结果是有更多的资源可以提供给其它任务。
微服务应用程序的另一个好处是，它们更快且更容易更新。当开发者对一个传统的单体应用程序进行变更时，他们必须做详细的QA测试，以确保变更不会影响其他特性或功能。但有了微服务，开发者可以更新应用程序的单个组件，而不会影响其他的部分。测试微服务应用程序仍然是必需的，但它更容易识别和隔离问题，从而加快开发速度并支持DevOps和持续应用程序开发。
第三个好处是，微服务架构有助于新兴的云服务，如事件驱动计算。类似AWS Lambda这样的功能让开发人员能够编写代码处于休眠状态，直到应用程序事件触发。事件处理时才需要使用计算资源，而企业只需要为每次事件，而不是固定数目的计算实例支付。
MVVM
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验，如Silverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由来便是MVP（Model-View-Presenter）模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去，以应对客户日益复杂的需求变化。
云原生
如果业务上云之后，开发和运维人员比上云之前还痛苦，那么上云的意义何在？
2015年，由Google提议创立的CNCF云原生基金会（Cloud Native Computing Foundation）正式成立，并且发布其标志性产品K8s，云原生也因此誉满天下。
云原生（Cloud Native）并不是新技术，而是一种理念，它是不同思想的集合，集目前各种热门技术之大成，它的意义在于让上云成为潮流而不是阻碍。云原生应用，即指专门为在云平台部署和运行而设计的应用。
很多公司在完成从传统应用到云端应用的迁移过程中，遇到了或多或少的技术难题，云端应用的效率并没有实现预想的明显提升，升级迭代速度和故障定位也没有预想中快。因此云原生这一概念被提出，试图同步改进应用的开发模式，提升运维效率和企业的组织结构。
云原生定义了云端应用应该具备的基础特性，包括敏捷、可靠、可扩展、高弹性、故障恢复、不中断业务持续更新等。总的来说，云原生是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。云原生既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。因此，云原生也可以说是一系列云技术、企业管理方法的集合。
