区分这两条线的核心就是在工程和技术实践上 ， 它决定我们积累的到底是资产还是债务 ， 也最终决定了长期的效率 。
领域驱动的架构和实现
在技术方面 ， 我们要持续积累并维护好领域资产 ， 让它易于理解、扩展、维护和复用 ， 今天业界普遍都认识到领域驱动设计的重要性 ， 也愿意投入精力 。 然而 ， 领域驱动设计要发挥作用并不容易 。
领域驱动设计不仅仅是设计的问题 ， 它是涉及需求、架构和实现的系统工程 。 需求和业务是源头 ， 架构是枢纽 ， 而他们都需要落地到现实当中 。 最重要的是如何把需求、架构和实践真正连接起来 ， 连接他们的是领域模型 。
如上图所示 ， 我们从业务需求开始去分析业务流程 ， 基于业务流程分解和设计产品需求 ， 通过实例化需求定义验收测试 ， 澄清和细化产品需求 。 更重要的是 ， 在整个的需求分析的阶段中 ， 我们要不断地提取和精化领域模型 。 因为对领域的认识和抽象来自于每个具体的业务、具体的需求 ， 所以被称为“业务引领的领域建模” 。
领域模型应该成为应用架构设计的基础 。 我们基于领域模型去划分子域 ， 设定子域的上下文 ， 基于领域模型去定义接口的设计契约 ， 划分子域和限界上下文 ， 并约束微服务的边界 ， 让微服务成为可复用的领域资产 。 限界上下文和服务契约最终保障领域资产的可复用 。 所以我们称为“领域引领的微服务架构” 。
在实现上 ， 领域模型、验收测试、服务设计契约都是高质量代码的约束和指导 。 我们的代码要体现领域模型 ， 与架构和接口契约一致 ， 并符合相关验收标准 。
同时 ， 测试先行的方式 ， 让我们有更靠谱的自动化测试 ， 而自动化测试会让我们的重构更有保障 。 持续的重构又保证代码资产不会快速腐化 ， 维持系统健康 。
今天分享的更多还停留在概念层面 ， 但是我希望能在思考规划上给大家带来启发 。 除非你认为你可以牺牲长期的质量 ， 你不需要积累一个长期可重复的资产 ， 那么上述这些都是不可或缺的 。
标准化的工程基础设施
接下来我们看工程部分 。 今天比较幸运的是 ， 我们看到工程部分的技术趋势正在收敛 。
我们看到基于容器管理和分发制品 ， 基于k8s编排环境资源这一部分已成为了一个事实 ， 大家都不再考虑要不要做 ， 而是什么时间做 ， 或者怎么做的问题 。 这个方向大概率不会改变 。 但问题是 ， 我们讲容器 ， 更多还是站在资源的视角去看 ， 即站在运维的视角 ， 但是在开发视角 ， 看到的是代码 ， 代码对应的是应用 。 如果仅做到这一点 ， 开发和运维之间还是有隔阂 ， 他们所面对的对象就不同
今天我们看到另外一个趋势 ， 是基于OAM的标准去做应用管理 。 OAM的标准是阿里和微软共同提出的叫做开放应用模型 ， 基于OAM可以管理应用的开发、编排和运维 。 OAM是一个标准 ， 基于这个标准 ， 开发可以声明式地编排应用 ， 运维也可以基于已有的声明进行自动化的运维 。
OAM 面向应用的部署和运维的终态 ， 统一了应用开发和运维的基本模型 。 它首先提出了应用描述的基本模型 ， 包括应用的拓扑、资源依赖、部署方式、运维方式等 ， 然后定义声明式的应用编排、部署和运维方式 。 OAM基于应用 ， 统一了开发和运维的基本语言 ， 让应用成为开发和运维共同的关注和操作的基本对象 ， 解决了技术基础实施的问题 ， 让真正的DevOps 成为可能 。
但是这个离真正的DevOps还差一点 ， 我们刚才讲的只是我们有了DevOps的基础 ， 我们从部署这个阶段基于这样的标准 ， 但是我们还没有定义我们的应用是怎么交付的 。 如果把应用和交付这一部分也包含进去 ， 就会实现真正的DevOps 。
相关经验推荐
- 一加科技|iPhone13Pro、一加9Pro和一加10pro之间，该如何选？
- 小米科技|时讯：MIUI 13稳定版更新，小米12新增内存扩展功能
- 小米科技|Intel/AMD/NV等撑不住！CPU、GPU等今年都要大涨价
- 小米科技|2022拍照最好的几款手机，堪比小单反，经常拍照的可以考虑一下
- 小米科技|12GB+256GB+120W快充，高配陶瓷旗舰机再次跌价，价格更亲民了
- 一加科技|别不舍得花钱，这4款手机一步到位，用个3-5年没问题
- 小米科技|小米手机用一年了，现在电池严重不行，10%以下就自动关机
- 小米科技|三款骁龙8旗舰，续航“测到死”！小米12Pro表现意外
- 小米科技|告别1999！红米K50太强：小米12X很尴尬，但雷军还是出手了
- 小米12|?力压小米12，拿到年度“最佳产品奖”，2999元起