落地DDD是一件很困难的事情。首先在思想认知层面就比较难以突破，这篇文章记录我对DDD的学习、感悟与项目工程代码重构实战心得！
在分布式系统应用中，高可用、一致性是经常面临的问题，针对不同的应用场景，我们会选择不同的架构方式，比如master-slave、基于ZooKeeper选主。随着时间的推移，出现了基于Raft算法自动选主的方式，Raft是在Paxos的基础上，做了一些简化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理解和算法实现上都相对容易许多。
本文记录Pipeline设计模式在业务流程编排中的应用前言Pipeline模式意为管道模式，又称为流水线模式。旨在通过预先设定好的一系列阶段来处理输入的数据，每个阶段的输出即是下一阶段的输入。本案例通过定义PipelineProduct（管道产品），PipelineJob（管道任务），PipelineNode（管道节点），完成一整条流水线的组装，并将“原材料”加工为“商品”。其中管道产品负责承载各
我们有时候也会看到一些博客看到或者听到一些同事在说：这个业务有什么难的，不就是CRUD么？在软件生命周期初期，我们通过CRUD这种方式我们可以快速的实现业务规则，交付项目，但随着业务逐渐复杂，通过CRUD这种粗暴方式不可避免地会淹没业务核心规则，产生很多祖传（屎山）代码，系统交接的时候我们经常会听到，上一个开发是SB，或者自嘲自己是在屎山上面继续堆屎。
简介Batrix企业能力库，是京东物流战略级项目-技术中台架构升级项目的基础底座。致力于建立企业级业务复用能力平台，依托能力复用业务框架Batrix，通过通用能力/扩展能力的定义及复用，灵活支持业务差异化场景的快速能力编排组装，从而通过技术驱动的方式助力业务整体交付吞吐率。在四层架构(接入层、交易层、履约层、执行层)的背景下，交易平台组承接交易层的业务逻辑，负责交易场景下的可复用能力开发。当前时间
我们在刚开始架构设计时手足无措，但是随着我们完成一个又一个的系统架构设计以后，发现架构设计是有章法可循的，只要我们学习这些章法和套路，并且在工作过程中不断的积累与沉淀，就会行成一个完整的架构设计方法论，面对新的大型系统架构设计，也会一步一步有节奏进行，最终完成整体的架构设计。
重构有利于项目的健壮和精简，平时要养成重构的好习惯，“小步快走”，尽量避免留着统一重构的思想，积累很多技术债后重构精力、时间成本很大，风险也会大很多。
前言趁着双十一备战封板，终于又有一些时间可以梳理一下最近的心得。最近这半年跟同事讨论比较多的是分层架构，然后就会遇到两个触及灵魂的问题，一个是如何做好分层架构，二是DDD在架构层面该如何落地。为了说好分层，我们需要了解架构的意义。良好的架构是为了保证一下两点：治理应用复杂度，降低系统熵值；从随心所欲的混乱状态，走向井井有条的有序状态。比如，你去图书馆借阅书籍，对于纷繁杂乱的各类书籍，如果不能很好的
一、重构背景1.1、退款到家、小时购、天选退款有2套结构，代码逻辑混乱；其中小时购、天选部分售后单是和平生pop交互退款，部分是和售后中台交互退款；并且兼容3套逻辑；痛点：代码繁重，缺乏合理性的设计，后续迭代开发以及维护成本高，同时增加了系统的风险和不稳定性1.2、金额计算到家、小时购两套独立的逻辑结构计算，在此基础上针对退差和非退差又实现了2套逻辑；针对商品件维度、商品行维度、售后单维度计算金额
架构的范畴太大太广，本文尝试从一个点切入阐述一下个人的认知。有太多相关性的问题想去阐述，比如SOA与BPM的结合、实践过程中遇到的细节问题等等，为了比较干净的剖析SOA还是删除掉了。希望各位看官有所收获。
本文从系统建设的背景、设计细节、已支撑案例及适用业务场景多个层面进行详细阐述。读者可以关注文中所讲的系统实践过程，进而对结算领域系统设计能力提升，具有一定的参考价值
今天的话题，我们从一个案例开始谈起。国际计费系统会定期自动生成账单，然后每个账单会按照预设的规则自动进入结算流程，账单从生成之后到结算完成，这期间需要销售支持、结算岗、客户（商家或服务商）、财务、资金等多个不同岗位角色的人员共同参与处理，每个角色处理的环节和操作内容不同，账单的状态也持续发生着改变。1 为什么要使用状态机下面这张图，描述了海外应收账单整个生命周期内的全部状态，以及每个状态下可以进行
本文介绍了一种基于线上流量实现对重构系统进行功能和性能验证的实践方案。针对线上流量如何拦截、如何录制、如何存储、如何回放以及如何发压均作了详细说明，为具有类似需求的读者提供了一种可供参考的思路。
弹性设计的核心思想是预见并应对系统可能面临的风险和挑战，这需要对系统的需求、架构、组件和服务进行深入的理解和管理。弹性设计还强调了自动化和快速响应的重要性，以便在问题发生时，能够迅速地检测到问题并采取相应的措施。
目前大部分运营后台的设计和开发都是由后端同学来做，产品经理对界面标准要求并不高，大多数都是能用就行。其实，只要花些心思，运营后台也可以做的很美，提升运营同学的日常使用体验。下面跟大家分享两个我做的运营后台中的订单详情设计
一、订单系统概述1.1 业务范围服务业务线：快递、快运、中小件、大件、冷链、国际、B2B合同物流、CLPS、京喜、三入三出（采购入、退货入、调拨入、销售出、退供出、调拨出）等1.2 订单中心价值1、解耦（提升系统稳定性）**原系统：**交易与生产耦合在一起，业务新增需求，涉及个上下游多个系统。ECLP、外单、运单、终端系统等。多条业务线的逻辑耦合在一起，单一业务条线的需求改动，涉及原系统中其他业务
本文与大家一起学习并介绍领域驱动设计(Domain Drive Design) 简称DDD，以及为什么我们需要领域驱动设计，它有哪些优缺点，尽量用一些通俗易懂文字来描述讲解领域驱动设计
本文是京东到家自动化测试体系建设过程中的一些回顾和总结，删减了部分系统设计与实践的章节，保留了组织与文化相关的内容，整理成文，以飨读者。
我们团队一直在持续推进业务系统的体系化治理工作，在这个过程中我们沉淀了自己的DDD脚手架项目。本文主要是梳理和总结了DDD脚手架使用中的编码规范以及遇到的问题。
伴随物流行业的迅猛发展，一体化供应链模式的落地，对系统吞吐、系统稳定发出巨大挑战，库存作为供应链的重中之重表现更为明显
从研发的角度来看如果系统上下文清晰、应用架构设计简单、应用拆分合理应该称之为架构合理。基于以上的定义可以从以下三个方面来梳理评估：
充血模型是DDD分层架构中实体设计的一种方案，可以使关注点聚焦于业务实现，可有效提升开发效率、提升可维护性；
在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性，关于一致性的补偿，已经由算法部的大佬总结过就不再赘述。这里主要讲如何去补偿？补偿的方案哪些？这就引出来数据监控系统了。有小伙伴会问了，为什么业务状态监控系统可以做补偿？别急，往下看。
DDD领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解DDD到底是什么，解决了什么问题，及一些建议和实践。本文主要是思想的一种碰撞和分享，希望能对朋友们有所启发或帮助。
浏览记录系统主要用来记录京东用户的实时浏览记录，并提供实时查询浏览数据的功能。在线用户访问一次商品详情页，浏览记录系统就会记录用户的一条浏览数据，并针对该浏览数据进行商品维度去重等一系列处理并存储。然后用户可以通过我的京东或其他入口查询用户的实时浏览商品记录，实时性可以达到毫秒级。目前本系统可以为京东每个用户提供最近200条的浏览记录查询展示。
采用依赖倒置原则后的分层架构和六边形架构，实际上都符合整洁架构设计理念。但是六边形架构中使用端口与适配器，让应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动，同时能够让应用程序边界更加清晰，从而能更好地防止领域层和应用层逻辑泄露到外层。
本文详细介绍了搭建系统工程架构时需要关注的几个重要方面。基于产品的价值，做出决策。并从系统工程架构的演进、技术方案的选型、系统规范共识的达成等方面入手，对实施过程中的常见问题给出了解决思路。
清晰架构是将领域驱动、整洁架构等架构的部分优势整合之后产生的另一种架构，因其2017年已经出现，已经不算是一种新的架构，实际应用的项目尚且较少。以下主要介绍架构的形成及各步骤的意义
20w的QPS的场景下，服务端架构应如何设计？常规解决方案可使用分布式缓存来抗，比如redis集群，6主6从，主提供读写，从作为备，不提供读写服务。1台平均抗3w并发，还可以抗住，如果QPS达到100w,通过增加redis集群中的机器数量，可以扩展缓存的容量和并发读写能力。同时，缓存数据对于应用来讲都是共享的，主从架构，实现高可用。
在互联网架构设计中，高可用是必不可少的环节，要从网络架构、服务架构、数据架构以及软硬件架构等多方面来分析设计，是架构师必备的技能之一。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
