JDDTechTalk的博客

本章以实时OALP引擎Clickhouse(简称ck)为例, 以其面向场景, 架构设计, 细节实现等方面来介绍, 深度了解其如何成为了OLAP引擎中的性能之王.

重构有利于项目的健壮和精简，平时要养成重构的好习惯，“小步快走”，尽量避免留着统一重构的思想，积累很多技术债后重构精力、时间成本很大，风险也会大很多。

从接触领域驱动设计的初学阶段，到实现一个旧系统改造到DDD模型，再到按DDD规范落地的3个的项目。对于领域驱动模型设计研发，从开始的各种疑惑到吸收各种先进的理念，目前在技术实施这一块已经基本比较成熟。在既往经验中总结了一些在开发中遇到的技术问题和解决方案进行分享。

本文是早些年，Paas化刚刚提出不久时，基于部门内第一次Paas化热部署落地经验所写，主要内容是如何构建一些热部署代码以及一些避雷经验。

对软件内部结构的一种调整，目的是在不改变软件观察行为的的前提下提高其可理解性、降低其修改成本；

本文从系统建设的背景、设计细节、已支撑案例及适用业务场景多个层面进行详细阐述。读者可以关注文中所讲的系统实践过程，进而对结算领域系统设计能力提升，具有一定的参考价值。

本文介绍了一种基于线上流量实现对重构系统进行功能和性能验证的实践方案。针对线上流量如何拦截、如何录制、如何存储、如何回放以及如何发压均作了详细说明，为具有类似需求的读者提供了一种可供参考的思路。

针对改动范围大、影响面广的需求，我通常会问上线了最坏情况是什么？应急预案是什么？你带开关了吗？。当然开关也是有成本的，接下来本篇跟大家一起交流下高频发布支撑下的功能开关技术理论与实践结合的点点滴滴。

在线上问题修复后，编写COE(Center of Excellence)复盘报告是非常重要的一步。在这个报告中，我们可以回顾整个问题的处理过程，思考如果当时做了哪些可以更快缩短MTTR(Mean Time To Repair)的方法。具体来说，我们可以从以下几个方面入手：分析问题出现的原因：首先需要对问题进行深入的分析，找出问题的根本原因。只有找到问题的根源，才能够采取有针对性的措施来解决问题，从而缩短MTTR。总结经验教训：在分析问题的过程中，我们需要总结经验教训，并提出改进建议。

通过技术中台架构升级项目，将交易体系以新的接入-交易-履约-执行四层架构进行重新搭建。其中交易订单负责物流与客户之间产生物流服务契约的单据流量收口，同时承载向下游OFC（订单履约层）分发的职责。

本文与大家一起学习并介绍领域驱动设计(Domain Drive Design) 简称DDD，以及为什么我们需要领域驱动设计，它有哪些优缺点，尽量用一些通俗易懂文字来描述讲解领域驱动设计

基于传统认知，前端产品直接触达消费者，往往具有高度的定制化、需求变更频繁等特点，要求具有很好的动态性, 能够满足不同客户的需求。那么能否建设类似的前端中台产品，我们姑且称之为“前端领域产品”，实现接入团队端到端能力复用呢？我们在撮合业务线中进行了一系列思考和探索。

本文是京东到家自动化测试体系建设过程中的一些回顾和总结，删减了部分系统设计与实践的章节，保留了组织与文化相关的内容，整理成文，以飨读者。

我们团队一直在持续推进业务系统的体系化治理工作，在这个过程中我们沉淀了自己的DDD脚手架项目。本文主要是梳理和总结了DDD脚手架使用中的编码规范以及遇到的问题。

复制，即在不同的节点上保存相同的副本，提供数据冗余。如果一些节点不可用，剩余的节点仍然可以提供数据服务，这些节点可能部署在不同的地理位置，以此来改善系统性能

DDD领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解DDD到底是什么，解决了什么问题，及一些建议和实践。本文主要是思想的一种碰撞和分享，希望能对朋友们有所启发或帮助。

本文重点介绍了京东零售电商业务在订单逆向履约上面的最佳技术实践，阅读本文，读者可以了解到整个快退平台新系统设计的底层逻辑，也可以参考本文并结合实际场景，将方案应用在遗留债务系统改造、业务和技术建模中。

清晰架构是将领域驱动、整洁架构等架构的部分优势整合之后产生的另一种架构，因其2017年已经出现，已经不算是一种新的架构，实际应用的项目尚且较少。以下主要介绍架构的形成及各步骤的意义

本文详细介绍了搭建系统工程架构时需要关注的几个重要方面。基于产品的价值，做出决策。并从系统工程架构的演进、技术方案的选型、系统规范共识的达成等方面入手，对实施过程中的常见问题给出了解决思路

对于中大型移动端APP开发来讲，组件化是一种常用的项目架构方式。个人最近几年在工作项目中也一直使用组件化的方式来开发，在这过程中也积累了一些经验和思考。主要是来自在日常开发中使用组件化开发遇到的问题以及和其他开发同学的交流探讨。