软件架构

一、背景简介 站长工作台，致力于为京东物流所有站长、运营管理人员提供高效工作平台，拥有多元化的业务形态。我们力求提升团队研发效率、实现敏捷业务交付，以打造一支具备灵活性、高度协作和强适应能力的敏捷团队

落地DDD是一件很困难的事情。首先在思想认知层面就比较难以突破……这篇文章集记录我对DDD四弹的学习、感悟与项目工程代码重构实战的心得！

在分布式系统应用中，高可用、一致性是经常面临的问题，针对不同的应用场景，我们会选择不同的架构方式，比如master-slave、基于ZooKeeper选主。随着时间的推移，出现了基于Raft

本文重点为管道模式的抽象与应用，上述示例仅为个人理解。实际应用中，此案例长于应对各种规则冗杂的业务场景，便于规则编排

我们有时候也会看到一些博客看到或者听到一些同事在说：这个业务有什么难的，不就是CRUD么？在软件生命周期初期，我们通过CRUD这种方式我们可以快速的实现业务规则，交付项目，但随着业务逐渐复杂，通过CR

作者查阅了Sentinel官网、51CTO、CSDN、码农家园、博客园等很多技术文章都没有很准确的springmvc集成Sentinel的示例，因此整理了本文，主要介绍SpringMvc集成Se

Batrix企业能力库，是京东物流战略级项目-技术中台架构升级项目的基础底座。致力于建立企业级业务复用能力平台，依托能力复用业务框架Batrix，通过通用能力/扩展能力的定义及复用，灵活支持业务

设计一个系统的过程，就是建造一座大厦的过程，架构设计的质量直接决定了大厦的质量。 在我们进行系统的架构设计时，总是会遇到一系列的问题，比如一个大型系统的架构应该如何起步，从哪里开始设计？系统是否应该划

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

重构有利于项目的健壮和精简，平时要养成重构的好习惯，“小步快走”，尽量避免留着统一重构的思想，积累很多技术债后重构精力、时间成本很大，风险也会大很多。如果重构任务艰巨，需要提前做好迭代计划，重构方案设

趁着双十一备战封板，终于又有一些时间可以梳理一下最近的心得。 最近这半年跟同事讨论比较多的是分层架构，然后就会遇到两个触及灵魂的问题，一个是如何做好分层架构，二是DDD在架构层面该如何落地。 为

从接触领域驱动设计的初学阶段，到实现一个旧系统改造到DDD模型，再到按DDD规范落地的3个的项目。对于领域驱动模型设计研发，从开始的各种疑惑到吸收各种先进的理念，目前在技术实施这一块已经基

一、重构背景 1.1、退款 到家、小时购、天选退款有2套结构，代码逻辑混乱； 其中小时购、天选部分售后单是和平生pop交互退款，部分是和售后中台交互退款；并且兼容3套逻辑； 痛点：代码繁重，缺乏合理性

架构的范畴太大太广，本文尝试从一个点切入阐述一下个人的认知。有太多相关性的问题想去阐述，比如SOA与BPM的结合、实践过程中遇到的细节问题等等，为了比较干净的剖析SOA还是删除掉了。希望各位看官有所收

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

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

本文总结了软件开发过程中经常用到的基础常识，分为基础篇和实践篇两个篇章，其中基础篇中着重讲述了类，方法，变量的命名规范以及代码注释好坏的评判标准。实践篇中从类，方法以及对象三个层面分析了常见的技术概念

背景 随着业务的快速变化和技术的不断发展，系统面临着诸多挑战，例如流量峰值、依赖服务故障、硬件故障、网络中断、软件缺陷等，这些因素都可能影响到系统的正常运行。在这种背景下，弹性设计（Resilienc

一、订单系统概述 1.1 业务范围 服务业务线：快递、快运、中小件、大件、冷链、国际、B2B合同物流、CLPS、京喜、三入三出（采购入、退货入、调拨入、销售出、退供出、调拨出）等 1.2 订单中心价值

我们在上篇 高性能MySQL实战（一）：表结构 中已经建立好了表结构，这篇我们则是针对已有的表结构和搜索条件为表创建索引。