京东科技开发者

低代码工具链以"特定领域场景Low Code -> 映射和建模 -> 可视化搭建系统"为核心链路，不断标准化开发流程，为团队提高了整体研发效率，并实现了业务需求的快速交付。使团队的敏捷交付能力跃升至一个全新的高度。技术能力•前端低代码和后端低代码实现无缝衔接，进一步提升页面开发效率•实现组件间优雅地互联互通，打通和其它平台的连通性，敏捷实现复杂页面的构建•打造组件生态，支持外部研发进行组件扩展团队交付•从通用报表页和任务卡片页的低代码生成中汲取经验。

在DDD思想中，repository表示资源库的概念，用于区分数据模型和领域模型。它操作的对象是聚合根，因此它属于领域层。由于过去ER模型以及主流ORM框架的发展，让很多开发者对实体的概念还停留在与关系形数据库映射这个层面。从而导致实体只有空洞的属性，而实体的业务逻辑散落各个service、util、helper、handler等各种角落中。这种现象就被称为贫血模型现象。如何判断自己的工程是否有贫血模型现象？1、大量的XxxDO或者Xxx：实体对象只包含与数据库表映射的属性，没有行为或者及其少量的行为。

这篇文章主要是介绍CPU技术的发展，包括最近几十年CPU性能提升和半导体工艺发展，当前技术发展方向。希望可以帮助软件开发者理解CPU指令集和组成运行原理、CPU性能提升的现状和瓶颈、CPU技术发展方向会如何影响软件开发/设计的框架和编程思想。

在分布式系统应用中，高可用、一致性是经常面临的问题，针对不同的应用场景，我们会选择不同的架构方式，比如master-slave、基于ZooKeeper选主。随着时间的推移，出现了基于Raft算法自动选主的方式，Raft是在Paxos的基础上，做了一些简化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理解和算法实现上都相对容易许多。

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

我们有时候也会看到一些博客看到或者听到一些同事在说：这个业务有什么难的，不就是CRUD么？在软件生命周期初期，我们通过CRUD这种方式我们可以快速的实现业务规则，交付项目，但随着业务逐渐复杂，通过CRUD这种粗暴方式不可避免地会淹没业务核心规则，产生很多祖传（屎山）代码，系统交接的时候我们经常会听到，上一个开发是SB，或者自嘲自己是在屎山上面继续堆屎。

我们在刚开始架构设计时手足无措，但是随着我们完成一个又一个的系统架构设计以后，发现架构设计是有章法可循的，只要我们学习这些章法和套路，并且在工作过程中不断的积累与沉淀，就会行成一个完整的架构设计方法论，面对新的大型系统架构设计，也会一步一步有节奏进行，最终完成整体的架构设计。

趁着双十一备战封板，终于又有一些时间可以梳理一下最近的心得。最近这半年跟同事讨论比较多的是分层架构，然后就会遇到两个触及灵魂的问题，一个是如何做好分层架构，二是DDD在架构层面该如何落地。为了说好分层，我们需要了解架构的意义。比如，你去图书馆借阅书籍，对于纷繁杂乱的各类书籍，如果不能很好的管理和分类，必然会导致图书馆管理混乱，效率低下，使得图书馆不能正常运维。

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

实现State和Event接口，定义自己的状态和事件；定义枚举类并实现Transition接口，状态转换关系通过枚举值形式配置出来；继承SimpleFSMFrame类，调用上一步枚举类的values()方法并传入构造方法；/*** 适用于海外应收账单状态（相比跨境应收增加了3个新状态）*//*** 初始化一个状态机* @param initialState 初始状态*///调用自定义的状态转换关系枚举的values()方法获取到全部转换关系，然后传给父类的构造方法@Getter。

目前大部分运营后台的设计和开发都是由后端同学来做，产品经理对界面标准要求并不高，大多数都是能用就行。其实，只要花些心思，运营后台也可以做的很美，提升运营同学的日常使用体验。下面跟大家分享两个我做的运营后台中的订单详情设计。

充血模型是DDD分层架构中实体设计的一种方案，可以使关注点聚焦于业务实现，可有效提升开发效率、提升可维护性；

在大额的交易面前，系统的稳定性尤其重要，同时基金业务比较复杂，为保障每个地方的稳定，告警埋点很多，加上各种日终检查，出现很多新的问题。结合日常处理经验，我们重新思考是否有好的方式，提前发现异常，改善此事，于是在基金交易系统中做了一件事情，有效的提高了系统的稳定性

假设存在a个应用，按每个应用平均b个中高频接口, 每个接口对应c个调用方，限流规则配置那数量为(axbxc)，稍微有点规模的部门这个数量就能上万, 要想全面覆盖靠人工基本不可行。限流阈值会随着环境的变化而变化。正常的微服务限流工具都需要人工配置：支持应用负责人事先配置限流规则（接口+调用方+限流阈值），流量在阈值以下可以正常响应，超过阈值的流量会快速失败。系统资源到达使用率到达预警线的时候， 系统自动触发系统进行全面限流， 各接口的限流值根据应用当前的流量状态以及历史的流量状态而定。作者：京东零售 马坚。

采用依赖倒置原则后的分层架构和六边形架构，实际上都符合整洁架构设计理念。但是六边形架构中使用端口与适配器，让应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动，同时能够让应用程序边界更加清晰，从而能更好地防止领域层和应用层逻辑泄露到外层。

20w的QPS的场景下，服务端架构应如何设计？常规解决方案可使用分布式缓存来抗，比如redis集群，6主6从，主提供读写，从作为备，不提供读写服务。1台平均抗3w并发，还可以抗住，如果QPS达到100w,通过增加redis集群中的机器数量，可以扩展缓存的容量和并发读写能力。同时，缓存数据对于应用来讲都是共享的，主从架构，实现高可用。