什么是云原生：
-
云原生基金会：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更
-
阿里云 ：从技术的角度看，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点
Serverless架构
- 与第三方的后端即服务（Backend as a Service，BaaS）交互
- 在函数即服务（Function as a Service，FaaS）平台上运行函数式业务代码
中台
- 中台是将可复用的代码抽取到一个平台中，作为大家共用的软件组件，它是服务于前台的规模化创新
使用DDD 的时机
- 一个项目值不值得使用DDD有时不好判断。大项目往往是由小项目发展而来的，很多从小项目演化而来的大系统最终变成开发团队的噩梦，噩梦的根源几乎无一例外地在于软件的概念完整性遭到了破坏。而DDD正是维护软件概念完整性的良药。如果在项目中实践DDD的成本不高，那么即使是小项目，从一开始就使用DDD不是一件很美好的事情吗？
领域模型是什么
- 按照Eric Evans的观点，领域模型不是一幅具体的图，而是那幅图想要传达的思想；不是一个领域专家头脑中的知识，而是那些经过严格组织并进行选择性抽象的知识。
领域专用语言（DSL）领域
- DDD并不是只适用于大项目，使用DDD并不一定需要牺牲敏捷性，一切的关键在于DSL的运用
各个角色在DDD 上的使用 产品经理与系统分析师
- 产品经理不仅仅需要保证团队开发的是“正确的软件”，也不应该只是关注软件的界面原型、用户体验，更应该让软件有内涵。迷人的产品不仅需要漂亮的界面和交互，更需要逻辑自洽，功能处处传达出一个思想——优美而深刻的领域模型。在有的团队中，产品经理同时也是系统分析师。作为近十几年来最有影响力的软件分析和设计的方法论，系统分析师有必要了解DDD，从中汲取营养
架构师
- 架构师需要根据业务需求提供技术解决方案。DDD想要构建的领域模型不仅仅是领域业务知识的提炼总结，也包含了对软件设计的考量，可以用于直接指导软件的编码实现。构建这样的模型，需要架构师的积极参与
开发工程师
- 开发工程师应该理解领域模型，领域模型应该被忠实地映射到代码实现中。代码中对象的命名、对象之间的关系，都应该与领域模型一致。唯有如此，代码才能具备良好的可读性、可维护性，敏捷XP方法的狂热爱好者们所言的“代码即文档”才可能实现
测试工程师
- 如今很多测试工程师已经被称为“测试开发工程师”，他们也应该理解领域模型。测试工程师应该像产品经理一样了解软件的设计，甚至应该比产品经理更深刻地理解领域模型面向软件设计所做的考量。实例化需求的自动化测试（或者说行为驱动测试）应该基于领域模型，而非基于UI/UE来构建，因为用户界面以及用户交互是易变的，而领域模型相对来说稳定得多
项目经理
- 项目经理是负责“正确开发软件”的人。如果不深刻理解领域，不知道如何抓住领域模型中的关键点，会很难评估任务工作量的大小以及应该在何处投入足够的资源，甚至无法判断项目的实际进度
