
开发技巧
文章平均质量分 91
goTsHgo
这个作者很懒,什么都没留下…
展开
-
数据标准化——数据字典发布
数据字典发布是数据标准化的关键环节,为企业的数据治理、共享和使用提供了基础支持。从底层原理看,它通过标准化描述减少认知差异,促进数据资产化和治理闭环的实现。通过系统化的步骤,如内容规范、收集整理、发布与动态维护,企业能够确保数据字典的高效发布和持续利用,为业务决策和开发效率提供强有力的保障。原创 2025-01-17 17:23:05 · 1076 阅读 · 0 评论 -
数据入湖的前提条件:数据标准 之 元数据注册
是数据入湖的核心步骤,通过系统化管理元数据,确保数据的可发现性、可理解性、可追溯性和可治理性。它既是数据治理的基础设施,也是数据资产化的重要环节。只有完成元数据注册,才能真正实现数据湖中数据的高效管理和价值挖掘。元数据是描述数据的“数据”,包括数据的结构、来源、用途等关键信息。下面从底层原理、操作步骤及背后原因进行全面解析。记录和管理数据的元信息(Metadata),为数据的理解、发现、管理、使用和治理提供依据。是数据入湖的重要前提条件之一,其核心目的是。原创 2025-01-17 16:25:01 · 1034 阅读 · 0 评论 -
数据入湖的前提条件:数据标准 之 数据质量评估
是数据入湖前必须满足的核心标准之一,其目的是确保数据的准确性、完整性、一致性和可靠性。通过系统化评估,能够最大限度地提升数据的价值,降低数据问题对业务决策的负面影响。下面从底层原理、详细步骤及背后原因进行全面解析。数据质量评估是数据入湖前的重要保障,确保数据的真实性、完整性和可用性。通过质量评估,企业能够优化数据治理流程,提升数据的业务价值,原创 2025-01-17 16:15:28 · 952 阅读 · 0 评论 -
数据入湖的前提条件:数据标准 之 明确数据源
是数据入湖的重要前提,通过记录数据来源、生成逻辑、责任人和合法性,确保数据的真实性、可追溯性和合规性。它不仅是数据治理的基础,也是数据安全和高效管理的核心环节,能够有效避免“数据沼泽”、提升数据价值。确保数据的来源合法、清晰、可追溯,为数据的可靠性、完整性和可用性提供基础保障。下面从底层原理、具体操作以及其背后原因进行详细解析。是数据入湖的重要前提条件之一,其核心目的是。原创 2025-01-16 16:03:46 · 981 阅读 · 0 评论 -
数据入湖的前提条件:数据标准 之 定义数据密级
是数据入湖前必须完成的步骤,它确保了数据的安全性、合规性和高效管理。通过科学的密级分类、清晰的判定标准和有效的保护策略,企业可以在保护数据的同时,最大限度地支持业务需求,平衡安全与效率。是对数据敏感性和重要性的分类,明确数据的保密程度和使用权限。它是确保数据安全、合规、合理使用的关键环节。下面从底层原理层面逐步解析数据密级定义的原因及其详细实现步骤。原创 2025-01-16 15:27:42 · 652 阅读 · 0 评论 -
数据入湖的前提条件:数据标准 之 发布数据标准
在数据入湖(Data Ingestion)过程中,“发布数据标准”是确保数据治理规范化、数据质量一致性以及后续数据可用性的核心环节。从底层原理来看,数据标准的发布涉及定义、审核、发布和执行多个阶段,贯穿技术、业务和治理逻辑。总结而言,发布数据标准是数据入湖治理中不可或缺的环节,其从定义、发布到执行的全过程,构建了确保数据质量与规范性的系统性保障。数据标准是关于数据属性、结构、质量、语义等方面的规范,它是数据入湖的基础条件,发布数据标准不仅是定义标准,还涉及审核、发布和监督执行的流程。原创 2025-01-16 12:10:37 · 990 阅读 · 0 评论 -
数据入湖的前提条件:数据标准 之 明确数据Owner
明确数据Owner,就像给每一块“田地”分配一个具体的“农夫”。这个农夫负责田地的种植、维护、收获。如果田地没人管理,它可能荒废;如果有人管理,它就会不断产生价值。通过明确数据Owner,公司可以清楚知道数据的责任人是谁,提升数据质量,确保安全合规,最终让数据更高效地服务于业务需求。原创 2025-01-14 17:22:39 · 1236 阅读 · 0 评论 -
领域驱动设计(Domain-Driven Design,DDD)详解
领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,一种软件设计方法,帮助软件开发团队准确理解复杂业务需求,并创建反映这些需求的高效、可维护的软件系统。它强调的是基于业务领域的复杂性进行建模,并通过语言和实现这些模型的方法促进软件项目和业务专家之间的沟通。这种方法论特别适用于那些业务规则复杂、业务逻辑多变的环境。此设计方法由Eric Evans在其2004年的书《领域驱动设计:软件核心复杂性应对之道》中首次提出。原创 2025-01-10 16:45:28 · 1430 阅读 · 0 评论 -
领域驱动设计(DDD)——限界上下文(Bounded Context)详解
每个街区都有自己的规则和运作方式(比如商业区禁止夜间施工,住宅区保持安静),虽然它们同属于一个城市,但它们的行为是互相独立的。,帮助我们将复杂的业务系统划分成多个相对独立的上下文,每个上下文内都有自己独立的模型、规则和语义。这样,每个上下文的模型都是独立的,能够根据上下文的需求量身定制。限界上下文的一个重要原则是:每个上下文都应该是自治的,即使一个上下文失效,也不会影响到其他上下文的正常运行。通过限界上下文,我们能够构建出模块化、易维护且高效协作的业务系统,是 DDD 中解决复杂系统问题的重要策略。原创 2025-01-10 16:43:25 · 1202 阅读 · 0 评论 -
领域驱动设计(DDD)——实体(Entity)和值对象(Value Object) 详解和示例
例如,一个用户的 ID 是其身份的唯一标识,即使姓名或其他信息发生变化,用户的身份不变。值对象通常用来表示实体的属性或某些业务概念,帮助实体表达更复杂的业务逻辑,如地址(Address)、货币金额(Money)等。理解实体与值对象的区别和正确使用场景,可以帮助我们设计更清晰的领域模型,减少复杂度,增强代码的可维护性和可读性。即使实体的其他属性值发生变化,只要它的唯一标识(ID)保持不变,它仍然是同一个实体。值对象没有唯一标识,它通过属性值来判断是否相同(两个值对象如果属性值相同,就认为它们是相等的)。原创 2025-01-10 15:57:06 · 968 阅读 · 0 评论 -
领域驱动设计(DDD)——聚合 详解和示例
聚合根是聚合的入口点,对聚合内的所有对象负责。聚合帮助我们定义哪些对象需要一起变化、被一起操作,同时帮助我们控制领域模型的复杂性。原创 2025-01-09 15:51:50 · 766 阅读 · 0 评论 -
领域驱动设计(DDD)——仓储(Repository)详解和示例
*** 订单(Order):这是领域模型中的聚合根。* 聚合根是领域模型中的一个重要概念,表示领域的一部分及其边界。*/// 订单的唯一标识// 用户 ID// 订单总金额// 订单创建时间// Getter 和 Setter 方法/*** 订单仓储接口(Order Repository)。* 定义了对订单领域对象的基本操作。*//*** 保存订单。* @param order 要保存的订单对象*//*** 根据订单 ID 查找订单。原创 2025-01-09 12:29:57 · 1077 阅读 · 0 评论 -
领域驱动设计——触发领域事件 详解和示例
在领域驱动设计(DDD, Domain-Driven Design)中,“触发领域事件”是一个非常重要的概念。它涉及到如何在业务逻辑中表达和传播重要的状态变化,并实现系统中不同领域对象或模块之间的解耦与协作。下面具体解释这个概念。领域事件的定义领域事件是指在领域模型中发生的重要业务事件。这些事件是对领域中某些有意义的行为或状态变化的抽象描述,通常使用领域语言来表达。订单创建成功库存减少用户注册完成这些事件通常表示的是“已经发生的事情”,而不是未来要做的事情。它们是过去式的。触发领域事件的含义。原创 2025-01-09 12:09:34 · 709 阅读 · 0 评论 -
常见的架构模式 简介
不同的架构模式适用于不同场景,没有绝对的优劣。系统规模:单体架构适合小型项目,微服务适合大型系统。性能需求:事件驱动、CQRS 更适合高性能场景。复杂性:分层架构适合简单系统,DDD 适合复杂业务。团队能力:简单模式适合经验不足的团队,复杂模式需要更多经验。如果有具体场景,我可以帮助推荐合适的架构模式。原创 2024-12-31 11:39:38 · 1037 阅读 · 0 评论 -
可扩展性设计架构模式——分层架构
分层架构是一种软件设计模式,它将应用程序分割为互相独立的层次,每层都有其特定的职责。这些层次通常包括表示层、业务逻辑层、持久层和数据访问层。通过这种方式,每个层次都可以独立开发、测试和维护。在目录下创建一个新的package叫model,并创建一个Java类Product。@Entity // 表示这是一个与数据库表映射的实体类@Id // 表示这个字段是表的主键@GeneratedValue(strategy = GenerationType.AUTO) // 自动生成主键值。原创 2024-12-31 10:56:37 · 1181 阅读 · 0 评论 -
可扩展性设计架构模式——事件驱动架构
原理:在事件驱动架构中,一个事件代表了一个明确的状态变化或业务行为。定义事件是确定哪些动作或变化应当被系统捕捉并触发后续流程的关键步骤。操作步骤识别事件源:分析业务流程,找出需要触发通知的行为,例如订单的创建、支付和发货。定义事件结构:为每个事件定义必要的信息结构,如订单号、客户ID、商品详情等。事件驱动架构通过使用事件作为主要的通信方式,实现系统组件的高度解耦和动态互动。这种架构提供了高度的可扩展性和灵活性,特别适用于处理异步数据、实时响应以及构建微服务架构的系统。原创 2024-12-30 17:06:15 · 1231 阅读 · 0 评论 -
架构师需要具备的能力
一个优秀的软件开发者或架构师,需要具备扎实的技术能力系统性思维良好的沟通能力和持续学习的态度。可维护性、可扩展性、可重用性等这些具体指标,是在这些品质的基础上实现的结果。通过不断实践、反思和学习,开发者和架构师才能在快速变化的技术领域中脱颖而出。原创 2024-12-20 15:53:50 · 940 阅读 · 0 评论 -
系统设计:微服务架构的可扩展性系统 详解
微服务是一种分布式架构模式,将系统分解为多个小型、独立的服务,每个服务都实现一个特定的业务功能,并通过轻量级协议(如HTTP或gRPC)进行通信。核心思想:每个服务是独立的,围绕具体的业务能力(如订单、用户、支付)设计。原创 2024-12-20 15:46:37 · 927 阅读 · 0 评论 -
设计可维护的系统——测试设计 详解
单元测试验证每个方法的正确性。集成测试验证模块间的协作。Mock技术隔离外部依赖。JaCoCo监控覆盖率,发现未测试的代码。这种设计让系统的每个模块都独立、清晰,方便维护与扩展。原创 2024-12-20 12:16:09 · 638 阅读 · 0 评论 -
开发系统设计原则——单一职责原则(SRP) 详解
单一职责原则一个类应该只有一个导致其变更的原因。换句话说,每个类、模块或方法都应该有且只有一个职责(功能)。如果一个类有多个职责,那么这些职责可能会相互影响,使得系统更难维护和扩展。原创 2024-12-19 12:31:32 · 1027 阅读 · 0 评论 -
开发技巧——系统设计—模块化设计 详解
模块独立性用户、商品、订单各自独立,实现时互不干扰。每个模块都可以单独测试和复用。接口清晰每个模块对外暴露的方法简单明了,参数和返回值易于理解。可扩展性如果需要新增功能(例如库存管理),可以创建一个新的模块,不会影响现有模块。低耦合性模块之间只通过方法调用进行交互,内部实现对其他模块透明。通过这种模块化设计,我们构建了一个简单而灵活的电商系统,易于扩展、维护和理解。其实很简单。没有难度。原创 2024-12-19 12:23:31 · 2334 阅读 · 0 评论