搜索到
88
篇与
的结果
-
DDD业务服务的目录规划 DDD架构下的工程目录结构划分详解 在领域驱动设计(Domain-Driven Design, DDD)中，合理的工程目录结构对于实现复杂业务逻辑的清晰组织至关重要。本文将详细介绍基于DDD思想的工程目录划分方案，帮助开发团队更好地组织代码，提高系统的可维护性和可扩展性。 DDD工程目录的四层架构 根据思维导图所示，一个标准的DDD架构通常分为四个主要层次： 1. 接口层（interfaces） 接口层是系统与外部交互的门户，负责处理来自外部的请求，并将请求转发到应用层。 facade（统一对外接口）：提供RESTful API接口，处理HTTP请求和响应 config（spring mvc相关配置）：包含接口层相关的配置，如控制器配置、请求拦截器等 src/main/java/com/company/project/interfaces/ ├── facade/ # 外观模式，统一接口 │ ├── dto/ # 数据传输对象 │ ├── assembler/ # DTO与领域对象转换 │ └── controller/ # 控制器 └── config/ # 接口层配置 2. 应用层（application） 应用层是业务流程的协调者，负责组织领域对象完成特定的应用功能。 service（应用服务接口和实现包）：协调领域对象完成业务流程 assembler（DTO与Entity互相转换包）：负责应用层与领域层数据模型的相互转换 event（事件发布/订阅） ： publish（事件发布包）：发布领域事件 subscribe（消息订阅包）：订阅并处理领域事件 src/main/java/com/company/project/application/ ├── service/ # 应用服务 │ ├── impl/ # 应用服务实现 │ └── dto/ # 应用服务数据传输对象 ├── assembler/ # DTO与领域对象转换 └── event/ # 事件处理 ├── publish/ # 事件发布 └── subscribe/ # 事件订阅 3. 领域层（domain） 领域层是业务核心，包含业务规则和逻辑。 aggregate（聚合包） ：聚合是一组关联的实体和值对象的集合 entity（聚合根、实体、值对象）：领域模型核心元素 service（领域服务，处理特殊领域内业务）：处理跨实体的业务逻辑 src/main/java/com/company/project/domain/ ├── aggregate/ # 聚合 │ ├── order/ # 订单聚合（示例） │ │ ├── Order.java # 聚合根 │ │ ├── OrderItem.java # 实体 │ │ ├── OrderStatus.java # 值对象 │ │ └── OrderRepository.java # 仓储接口 │ └── user/ # 用户聚合（示例） └── service/ # 领域服务 └── impl/ # 领域服务实现 4. 基础设施层（infrastructure） 基础设施层为其他层提供技术支持。 repository（仓储数据库ORM层） ： po（数据库对象）：数据库表映射对象 assembler（entity转po）：领域对象与数据库对象转换 domain.impl（领域服务实现包）：领域服务的具体实现 config（基础配置）：系统基础配置 utils（基础工具类）：通用工具类 src/main/java/com/company/project/infrastructure/ ├── repository/ # 仓储实现 │ ├── po/ # 持久化对象 │ ├── assembler/ # 领域对象与持久化对象转换 │ ├── mapper/ # MyBatis映射接口 │ └── impl/ # 仓储接口实现 ├── domain/ # 领域层实现 │ └── impl/ # 领域服务实现类 ├── config/ # 基础配置 └── utils/ # 工具类 目录结构的实践建议 按领域划分而非技术功能：在DDD中，首先应该按照业务领域进行划分，而非按照技术功能（如controller、service、dao等） 考虑限界上下文：不同的业务上下文应该有清晰的边界，可以在目录结构中体现 聚合根作为目录划分的基础：每个聚合根可以作为一个子目录，包含相关的实体和值对象 保持领域逻辑的纯净：领域层不应依赖其他层，特别是不应依赖基础设施层 接口与实现分离：定义清晰的接口，并将实现放在适当的包中 示例目录结构（电子商务系统） src/main/java/com/ecommerce/ ├── interfaces/ │ ├── facade/ │ │ ├── order/ # 订单接口 │ │ └── product/ # 产品接口 │ └── config/ # 接口配置 ├── application/ │ ├── service/ │ │ ├── order/ # 订单应用服务 │ │ └── product/ # 产品应用服务 │ ├── assembler/ # DTO转换器 │ └── event/ │ ├── publish/ # 事件发布 │ └── subscribe/ # 事件订阅 ├── domain/ │ ├── aggregate/ │ │ ├── order/ # 订单聚合 │ │ ├── product/ # 产品聚合 │ │ └── user/ # 用户聚合 │ └── service/ # 领域服务 └── infrastructure/ ├── repository/ │ ├── po/ # 持久化对象 │ ├── assembler/ # 对象转换 │ └── impl/ # 仓储实现 ├── domain/ # 领域实现 ├── config/ # 系统配置 └── utils/ # 工具类 结语 DDD在项目中的应用还有待进一步验证，记录一下DDD业务服务的规划。 -
Git分支命名规范 Git分支命名规范 分支 命名 说明 主分支 master 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布 开发分支 dev 开发分支，永远是功能最新最全的分支 功能分支 feature- 新功能分支，某个功能点正在开发阶段 发布分支 realease- 发布定期要上线的功能 修复分支 fixbug-* 修复线上代码的 bug 主分支 Master 首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。 Git主分支的名字，默认叫做 Master 。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。 开发分支 Dev 主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做 Dev 这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在 Master 分支上，对 Dev 分支进行”合并”（merge）。 Git创建 Dev 分支的命令： git checkout -b dev master 将 Dev 分支发布到 Master 分支的命令： 切换到 Master 分支 git checkout master 对 Dev 分支进行合并 git merge –no–ff dev 这里稍微解释一下，上一条命令的–no–ff参数是什么意思。默认情况下，Git执行”快进式合并”（fast-farward merge），会直接将 Master 分支指向 Dev 分支。 使用–no–ff参数后，会执行正常合并，在 Master 分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。 功能分支 Feature 功能分支的名字，可以采用feature-*的形式命名。 创建一个功能分支： git checkout -b feature-x dev 开发完成后，将功能分支合并到dev 分支： git checkout dev git merge –no-ff feature-x 删除feature分支： git branch -d feature-x 预发布分支 Release 第二种是预发布分支，它是指发布正式版本之前（即合并到 Master 分支之前），我们可能需要有一个预发布的版本进行测试。 预发布分支是从 Dev 分支上面分出来的，预发布结束以后，必须合并进 Dev 和 Master 分支。它的命名，可以采用release-*的形式。 创建一个预发布分支： git checkout -b release-1.2 dev 确认没有问题后，合并到master分支： git checkout master git merge –no-ff release-1.2 对合并生成的新节点，做一个标签 git tag -a 1.2 再合并到dev 分支： git checkout dev git merge –no-ff release-1.2 最后，删除预发布分支(一般等发完版本后删除）： git branch -d release-1.2 修补分支 Bug 最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。 修补bug分支是从 Master 分支上面分出来的。修补结束以后，再合并进 Master 和 Dev 分支。它的命名，可以采用fixbug-*的形式。 创建一个修补bug分支： git checkout -b fixbug-0.1 master 修补结束后，合并到master分支： git checkout master git merge –no-ff fixbug-0.1 git tag -a 0.1.1 再合并到dev 分支： git checkout dev git merge –no-ff fixbug-0.1 最后，删除”修补bug分支”： git branch -d fixbug-0.1
-
K8S搭建准备工作全解析 K8S搭建准备工作全解析 在容器编排领域，Kubernetes（简称K8S）已然成为了事实上的标准。它能够高效地管理容器化应用程序，实现自动化部署、扩展和管理。然而，在搭建K8S集群之前，有一系列重要的准备工作需要完成。本文将结合思维导图，深入介绍K8S搭建的前期准备要点。 一、机器准备 搭建K8S集群，首先需要准备合适的机器资源，这里计划准备5台机器，每台机器都承担着特定的角色： 第一台：软件服务器 glt：可能是用于特定的版本管理或者代码托管等相关功能，是软件开发和部署流程中的重要一环。 ssr证书签发：负责生成和管理SSL/TLS证书，这些证书对于保障网络通信的安全性至关重要，能够防止数据在传输过程中被窃取或篡改。 docker-nginx网关：作为网关，它可以对进入集群的流量进行管理和转发，同时借助Docker进行部署，方便快捷且易于维护。 harbor docker仓库：用于存储和管理Docker镜像，是容器镜像的集中存储地，方便在集群中进行镜像的分发和部署。 第二台：DNS服务/代理分发 这台机器主要负责域名系统（DNS）相关的服务以及代理分发功能。DNS服务可以将域名解析为IP地址，使得用户能够通过易于记忆的域名访问集群中的服务。代理分发功能则可以根据一定的策略，将请求合理地分配到不同的后端服务器上，实现负载均衡。 第三台：代理分发 进一步强化负载均衡和请求分发的能力，通过合理的配置和算法，将网络请求均匀地分配到集群中的各个节点，避免单个节点负载过高，提高整个集群的性能和可用性。 第四台和第五台：service/pod节点 这两台机器作为service/pod节点，是运行K8S中服务（Service）和容器组（Pod）的关键所在。它们承载着具体的应用程序容器，通过K8S的调度和管理，实现容器的高效运行和资源分配。 二、第三方软件准备 除了机器资源，还需要安装和配置一系列第三方软件，这些软件在K8S集群中各自发挥着不可或缺的作用： etcd 高可用的服务发现与存储：etcd是一个分布式键值存储系统，它为K8S集群提供高可用的服务发现和配置存储功能。集群中的各种配置信息、服务注册信息等都可以存储在etcd中，方便各个组件进行读取和更新。 基于Raft算法：采用Raft算法保证数据的一致性和高可用性，通过选举领导者等机制，确保在多个etcd节点之间数据能够正确同步和处理。 proxy，apiserver的注册发现：帮助K8S中的代理（proxy）和API服务器（apiserver）进行注册和发现，使得各个组件之间能够准确地相互通信和协作。 supervisor 作为守护进程工具，supervisor的作用是对集群中的所有程序进行统一管理。它可以监控程序的运行状态，在程序意外终止时自动重启，确保集群中的各项服务能够持续稳定地运行。 flanneld flanneld负责创建和管理虚拟网络，它解决了容器之间的通信问题。通过为容器提供一个虚拟的网络环境，使得不同节点上的容器能够像在同一网络中一样进行通信，方便了容器化应用的部署和运行。 coredns DNS服务器/转发器：coredns作为K8S集群内部的DNS服务器，承担着域名解析和转发的任务。它能够将服务名称解析为对应的IP地址，实现K8S中的服务发现功能。 解决K8S的服务发现：在K8S中，服务的IP地址可能是动态变化的，coredns通过动态解析和更新，能够及时准确地将服务名称映射到正确的IP地址，确保服务之间的通信顺畅。 解决pod的问题：对于Pod，coredns同样重要。它可以处理Pod的IP地址动态变化情况，以及service资源的创建和销毁等情况，类似于域名和IP的关系，实现service的自动发现，保障Pod能够正确访问到对应的服务。 三、总结 K8S搭建准备工作涉及机器资源的合理规划和第三方软件的精心选择与配置。每一个环节都至关重要，它们相互配合，共同为构建一个稳定、高效、可用的K8S集群奠定基础。在实际搭建过程中，需要严格按照要求进行操作，并根据具体的业务需求和环境特点进行适当的调整和优化，只有这样才能充分发挥K8S在容器编排和应用管理方面的强大优势。
-
AlloyDesigner：前端开发者的利器 AlloyDesigner：前端开发者的利器 在前端开发和调试过程中，我们经常需要调整页面布局、对比设计稿、检查响应式效果等。而 Chrome 插件 AlloyDesigner 就是一款专门为前端开发者打造的工具，能够帮助我们更高效地进行页面设计对比和调整。 AlloyDesigner 是什么？ AlloyDesigner 是一款轻量级的 Chrome 浏览器扩展，主要用于网页设计稿和实际页面的比对。它提供了 标尺、参考线、对比叠加、元素对齐 等功能，让开发者可以更加直观地调整网页，确保像素级的精准布局。 主要功能特点 1. 设计稿与页面的精准对比 可以直接在网页上上传设计稿（支持 PNG、JPG），并调整透明度，与实际页面进行对比。 提供 蒙版、对比滑块 等方式，帮助开发者快速发现页面与设计稿的差异。 2. 标尺与参考线 AlloyDesigner 提供了 垂直和水平标尺，可以精确测量网页元素的位置。 参考线功能可用于对齐关键 UI 元素，确保页面布局的精确度。 3. 便捷的标注和测量 允许用户手动标注重要元素的位置、大小等。 提供 自动测量 功能，帮助开发者快速获取元素的尺寸、间距。 4. 响应式开发支持 可以调整浏览器窗口大小，查看不同分辨率下的页面效果。 帮助开发者更方便地适配各种设备屏幕。 为什么推荐 AlloyDesigner？ 轻量便捷：不需要复杂的配置，安装即用。 像素级精准比对：确保设计稿与开发结果的完美匹配。 提高效率：减少手动测量和调整的时间，提高前端开发效率。 免费开源：作为一款免费的 Chrome 插件，AlloyDesigner 适用于所有前端开发者。 如何安装和使用？ 安装步骤 打开 Chrome 浏览器，进入 Chrome Web Store。 搜索 AlloyDesigner，点击 添加到 Chrome 进行安装。 安装完成后，在扩展程序中找到 AlloyDesigner，固定到工具栏。 使用方法 打开你要调试的网页。 点击浏览器工具栏中的 AlloyDesigner 图标。 上传设计稿，调整透明度，对比实际页面。 使用标尺、参考线等工具，精细调整网页布局。 总结 对于前端开发者来说，AlloyDesigner 是一个不可多得的实用工具，能够帮助我们快速对比设计稿与页面效果，提高开发效率。如果你还在手动测量元素对比，不妨试试 AlloyDesigner，它一定能给你带来更高效的开发体验！ 你是否使用过 AlloyDesigner？欢迎在评论区分享你的使用心得！
-
ShardingSphere使用中的重点问题剖析 ShardingSphere使用中的重点问题剖析 一、引言 ShardingSphere是一款强大的分布式数据库中间件，在助力应用实现数据分片、读写分离等功能方面表现卓越。然而，在实际应用过程中，会遇到一些关键问题。本文将结合思维导图，深入探讨ShardingSphere在读写分离和事务处理方面的重点问题及应对策略。 二、读写分离相关问题 （一）数据库主从同步延迟问题 在读写分离架构下，主库负责写入操作，从库承担读取操作。但由于主从库之间的同步存在延迟，可能导致从库读取到的数据并非最新。 解决方案一：提供同一个线程的Ddl执行统一库。即对于在同一个线程内的一系列数据定义语言（DDL）操作，确保都在主库上执行，这样可以避免主从同步延迟带来的数据不一致问题，因为在同一线程内操作主库，能保证数据的实时性和一致性。 解决方案二：提供Hint强制读写库。通过特定的Hint机制，开发者可以在代码中明确指定某些查询操作必须在主库上执行，绕过从库，从而获取最新的数据，适用于对数据实时性要求极高的场景，如金融交易中的账户余额查询等。 （二）强制读主问题 当应用需要获取最新数据时，可能会面临强制读主的需求。但在现有的读写分离架构下，常规的基于对象关系映射（ORM）的基础增删改查（CRUD）操作可能无法直接满足这一要求。 解决方法：需要重构ORM封装的基础CRUD。通过对ORM框架进行定制化开发或扩展，使其能够支持根据业务需求灵活选择从主库还是从库进行读取操作。例如，在特定的业务方法中，通过修改ORM的查询逻辑，添加强制读主的标识，让查询直接路由到主库，保证数据的及时性。 （三）Sql兼容问题 在使用ShardingSphere进行读写分离时，部分SQL语句可能会出现兼容性问题。 部分Sql语句不支持，需要换语句：例如“Select Distinct Test_Int From T_Order;”这样的语句可能无法直接在ShardingSphere环境下正常执行。此时，开发者需要根据ShardingSphere的语法和规则，对SQL语句进行改写，以满足数据库的操作要求。 Union（合并）相关语句示例：像“Select User_Id, Order_Id, Status From T_Order Union All Select Item_Id, Order_Id, User_Id From T_Order_Item”这样的Union操作语句，在使用时也需要注意其在ShardingSphere中的兼容性。可能需要对表结构、字段类型等进行进一步的检查和调整，确保Union操作能够正确执行，实现数据的合并查询需求。 三、事务问题 （一）Sharding-Jdbc不支持强事务 Sharding-Jdbc作为ShardingSphere的一种使用模式，在事务处理方面存在一定局限性，它不支持传统的强事务（如严格的ACID事务）。 解决策略一：尽量在业务处理事务。在应用层的业务逻辑中，通过合理的流程设计和代码编写，将相关的操作进行分组和协调，以满足业务对数据一致性的要求。例如，在电商系统的下单流程中，通过在业务代码中依次处理库存扣减、订单生成等操作，并进行异常捕获和回滚处理，来模拟事务的一致性效果。 解决策略二：使用Sharding-Proxy，支持多种分布式事务。Sharding-Proxy提供了对分布式事务更好的支持，它可以采用两阶段提交（2PC）、TCC（Try - Confirm - Cancel）等多种分布式事务解决方案。对于一些对事务一致性要求较高的场景，如银行转账业务，可以使用Sharding-Proxy结合合适的分布式事务方案，确保跨库操作的数据一致性。 四、总结 ShardingSphere在实现读写分离和处理事务时，虽然存在一些棘手的问题，但通过合理的技术选型和针对性的解决方案，能够有效应对。在实际项目中，开发者需要深入理解这些问题的本质和解决方案的原理，根据业务场景的特点，灵活运用相关策略，以充分发挥ShardingSphere的优势，构建高效、稳定、可靠的分布式数据库应用系统。
