商品在电商领域中是一个非常重要的领域，交易行为前提是有商品信息存在。本文我们分析商品表基本设计，其它复杂场景可以在此基础上进行扩展。需要说明第一本文所用数据是测试数据，可能与真实数据有偏差，仅供演示。第二本文展示商品核心字段，一些通用字段不展示。
类目表示商品分类并且具有层级关系：
一级类目：图书
一级类目：电脑
一级类目：生鲜
后台类目有两个特点：标准和稳定。标准表示后台类目是业界通用的，并且层级不宜过多，通常不超过三级。稳定表示后台类目一旦确定不能轻易修改，否则设计上下游大量数据变更，工作量非常大，所以变更权限必须收敛到平台运营。
欢迎回来，我是飘渺。今天继续更新DDD&微服务的系列文章。
在前面的文章中，我们深入探讨了DDD的核心概念。我理解，对于初次接触这些概念的你来说，可能难以一次性完全记住。但别担心，学习DDD并不仅仅是理论的理解，更重要的是将这些理论应用到实践中，理解其设计原则和实施方法。就如同编程界的一句流行格言所说：“Don’t talk, Show me the Code”。
今天，我们将以实现用户注册流程为例，一步步展示如何在实践中应用DDD的设计思想和技术手段，这将有助于你更好地理解并记住DDD的核心概念。让我们一起开始吧！
在DDD的四层架构中，领域层扮演着核心角色。因此，我们首先着手实现这一层，其模块包结构如下：
大家好，我是飘渺。今天继续更新DDD&微服务的系列文章。
在专栏开篇提到过DDD（Domain-Driven Design，领域驱动设计）学习起来较为复杂，一方面因为其自身涉及的概念颇多，另一方面，我们往往缺乏实战经验和明确的代码模型指导。今天，我们将专注于DDD的分层架构和实体模型，期望为大家落地DDD提供一些有益的参考。首先，让我们回顾一下熟悉的MVC三层架构。
在传统应用程序中，我们通常采用经典的MVC（Model-View-Controller）架构进行开发，它将整体的系统分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。
在遵循此分层架构的开发过程中，我们通常会建立三个Maven Module：Controller、Service 和 Dao，它们分别对应表现层、逻辑层和数据访问层，如下图所示：
（图中多画了一个Model层是因为 Model 通常只是简单的 Java Bean，只包含数据库表对应的属性。有的应用会将其单独抽取出来作为一个Maven Module，但实际上它可以合并到 DAO 层。）
在我们之前设计的一个供应链系统中，它包含了商品、销售订单、加盟商、门店运营、门店工单等服务，涉及了各种用户角色，比如总部商品管理、总部门店管理、加盟商员工、门店人员等，而且每个部门的角色还会进行细分。而且这个系统中还包含了两个客户端 App：一个面向客户，另一个面向公司员工和加盟商。
此时，整个供应链系统的架构如下图所示：
上图中的网关层主要负责路由、认证、监控、限流熔断等工作。
大家好，我是飘渺。
在我们曾经设计的一个供应链系统中，存在商品、销售订单、采购这三个服务，它们的主数据的部分结构如下所示：
商品：
订单和子订单
采购单和子订单
今天我们来讨论如何在项目开发中优雅地使用RocketMQ。本文分为三部分，第一部分实现SpringBoot与RocketMQ的整合，第二部分解决在使用RocketMQ过程中可能遇到的一些问题并解决他们，第三部分介绍如何封装RocketMQ以便更好地使用。
在SpringBoot中集成RocketMQ，只需要简单四步：
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-spring-boot-starter</artifactId>
</dependency>研发工程师的职业成长路线，基本是初级研发工程师，进阶为中高级研发工程师，提升至架构师，然后再寻求更高的突破。这直接说明我们认同架构师的价值，想要努力成为架构师。虽然目标很明确，但我调研后发现，大多数研发工程师把“成为架构师”当作目标，但却没找到方法。
因为在工作中，不是每一个研发都有机会参与架构设计；很多公司也不会主动去培养你成为架构师。所以，有很多职场人在一家公司工作三年或五年之后并没有多大的提升。
而很多的架构师都是研发自己在机遇巧合下，遇到大项目、参与其中、趟了坑、解决了问题，最终形成自己的知识体系和解决问题的能力之后才成长起来的。那么如果没有这些条件，你还有没有途径成为一名架构师呢？
当然有，在我看来，你要先掌握架构师的知识体系，然后再通过实践进行检验，这样才能逐步成长为一名架构师。
很早以前，我曾写过两篇介绍如何在SpringBoot中使用Guava和Redis实现接口限流的文章。具体包括：
现在，一个问题摆在我们面前：如何将这两种限流机制整合到同一个组件中，以便用户随时切换呢？
显然，我们需要定义一个通用的限流组件，将其引入到业务中，并支持通过配置文件自由切换不同的限流机制。举例而言，当使用limit.type=redis时，启用Redis分布式限流组件，当使用limit.type=local时，启用Guava限流组件。这种自由切换机制能够为用户提供更大的灵活性和可维护性。
接下来，让我们开始动手实现吧！
大家好呀，我是飘渺。
现如今市面上注册中心的轮子很多，我实际使用过的就有三款：Eureka、Gsched、Nacos，由于当前参与 Nacos 集群的维护和开发工作，期间也参与了 Nacos 社区的一些开发和 Bug Fix 工作，过程中对 Nacos 原理有了一定的积累，今天给大家分享一下 Nacos 动态服务发现的原理。
不 BB，上文章目录：
