本文将带领大家从日常的三层架构出发，精炼推导出我们自己的应用架构，并且将这个应用架构实现为Maven Archetype，最后使用我们Archetype创建一个简单的CMS项目作为本文的落地案例。
不同团队落地DDD所采取的应用架构风格可能不同，并没有统一的、标准的DDD工程架构。即使无法制定通用的、标准的工程应用架构，但为团队制定一个遵循领域驱动设计思想的参考架构依然有价值。
性能优化是个系统性工程，宏观上可分为网络，服务，存储几个方向，每个方向又可以细分为架构，设计，代码，可用性，度量等多个子项。 本文将重点从代码和设计两个子项展开，谈谈那些提升性能的知识点。
大家好，今天我们来分享业务架构，但是我们并不是以产品经理角度讲述一个业务架构是什么以及如何做？而是以一个技术架构师的角度，讲述如何承接业务架构或在没有业务架构的时候，如何判断业务变化趋势而对系统架构提前做出反应。
本文将给大家介绍一种简洁明了软件架构可视化模型，并手把手教大家如何使用代码绘制出精美的架构图。
复杂系统的架构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。
门面模式和适配器模式是代码级的设计模式，而防腐层本质是一种防御型策略，在更高的层级对系统进行解耦。通常情况下，防腐层包含一系列的门面类和适配器类以及一些转换器类。
在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性，这里主要讲如何去补偿？补偿的方案哪些？这就引出来数据监控系统了。有小伙伴会问了，为什么业务状态监控系统可以做补偿？别急，且看本文。
设计是一个让人梦想成真过程，开始编码、测试、调试之前进行需求分析和架构设计，才能保证关键方面都做正确
作为一个技术架构师，不仅仅要紧跟行业技术趋势，还要结合研发团队现状及痛点，探索新的交付方案。在日常中，你是否遇到如下问题 “ 业务需求排期长研发是瓶颈；非研发角色感受不到研发技改提效的变化；引入ISV 团队又担心质量和安全，培训周期长“等等，基于此我们探索了一种新的技术体系及交付方案来解决如上问题。
软件工程的方方面面都遵循一个最基本的道理：没有银弹，架构分层模型更是如此，每一种都有各自优缺点，所以请根据不同的业务场景，并遵循简单、可演进这两个重要的架构原则选择合适的架构分层模型即可。
在日常工作中，我经常听到部分同学抱怨代码质量问题，潜台词是：“除了自己的代码，其他人写的都是垃圾，得送到绞刑架上，重构！”。今天就来聊一聊，如何写的一手好代码。
在现代大型分布式软件系统中，有一个绕不过去的课题，那就是如何保证系统的数据一致性。著名的Paxos算法（Megastore、Spanner），Raft协议（ETCD、TiKV、Consul ），ZAB协议（ZooKeeper）等分布式一致性解决方案，都是在此背景下而诞生的。
在敏捷开发环境下，系统通过迭代增量的交付价值，系统架构也是如此。团队不可能在项目之初就建立完美的系统架构，系统架构应该随着系统迭代不断演进。架构演进和架构腐化是看待架构的不同视角：架构腐化着眼于现状，架构演进侧重于未来架构腐化不可避免，随着时间流转腐化现象必然发生。而我们需要做的是：通过某种方式及早发现和修正
设计意图的传达是架构可视化关注的重要维度，在技术方案评审过程中不可避免的会出现各种各样的架构图或设计图，这些图形化表述在设计意图传达效果层面表现不一，本文从图形化的视角为软件架构图的评审关注点提供了参考。
CQRS只是一种非常简单的模式（pattern），CQRS本身并不是一种架构风格，和最终一致性/消息/读写分离/事件溯源/DDD等没有必然的联系，它最大优势是给我们带来更多的架构属性选择
作者：周可强一、责任链模式简介1、责任链模式定义责任链（Chain of Responsibility）模式的定义：为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，请求会自动进行
ADR 是一种性价比非常高的架构决策文档化实践，团队引入和实践成本很低，却能为团队带来极大收益！
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
