博文

目前显示的是与查询条件“应用层”相符的博文

基于 领域驱动设计DDD 的微服务设计和开发实战

postThumbnail
你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案。 本文是基于 DDD 的微服务设计和开发实战篇,通过借鉴领域驱动设计思想,指导微服务项目团队进行设计和开发(理论篇详见 《当中台遇上 DDD,我们该如何设计微服务?》 )。本文包括三部分内容:第一部分讲述领域驱动设计基本知识,包括:分层架构、服务视图、数据视图和领域事件发布和订阅等;第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容;最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。 目标 本文采用 DDD(领域驱动设计) 作为微服务设计指…

当中台遇上 领域驱动设计DDD,我们该如何设计微服务?

postThumbnail
借用当下最流行的段子做个开场白。 “设计原则千万条,高内聚低耦合第一条,架构设计不规范,开发运维两行泪!”。 在分布式架构下,单体应用被拆分为多个微服务,为了保证微服务的单一职责和合理拆分,“高内聚、松耦合”是最宝贵的设计原则。 通俗点讲,高内聚就是把相关的行为聚集在一起,把不相关的行为放在别处,如果你要修改某个服务的行为,最好只在一处修改。如果做到了服务之间的松耦合,那么修改一个服务就不需要修改另一服务,一个松耦合的服务应该尽可能少的知道与之协作的那些服务的信息。 从集中式架构向分布式架构的技术转型,正如从盖砖瓦房向盖高楼大厦转变一样,必然要有组织、文化、理念和设计方法的同步更新,其中最不可或缺的…

为什么要建模;怎么建模才合理;“领域”模型具体指什么?(DDD)

要回答这个问题,需要三步走:为什么要建模;怎么建模才合理;“领域”模型具体指什么。 为什么要建模 客户在专卖店买了个手机,留下了自己的名字和电话,店员做了记录。客人来时,只要店员能在记录里查到客人名字和电话的订单,就说明客人曾经买过手机。 什么人需要查看订单呢?店员 A 需要查看,店员 B 也需要查看。客人来咨询的时候,应该能随时调取。老板也需要查看,用来汇总销售情况。大家都要看,格式就必须统一,要不然有的只记了电话,有的只记了名字,有的什么都没记,就乱套了。 大家商量之后决定:订单必须包括客户名字、电话和购买的商品。那么就有“订单 = 名字 + 电话 + 商品信息”。这是店员和老板的 心智模型 me…

php应用容器化部署实践​

postThumbnail
目前市场上 php 仍有一席之地。本文章将探讨如何将 php 应用容器化并迁移部署到 TKE。 php 应用镜像准备 镜像的层次:基础依赖镜像->运行框架->应用/代码镜像 基于容器的单进程运行理念,下面的部署过程并未使用单体的 nginx+php-fpm 一体的容器运行方式,而是将 php-fpm 和 nginx 拆散。 基础镜像 安装基础系统依赖包和公司 php 应用中各个开发小组都会用到的扩展包。 下面的示例基于官方 fpm,安装了通用系统级的依赖和 php 包管理器。 如果可以,建议使用更基础的镜像从 php 源码进行编译。 # runtime . Dockerfile FROM php : 8…

此博客中的热门博文

youtuber油管主推荐

公众号推文镶嵌小程序

Podcast播客 Feed 订阅推荐