这是“领域驱动设计实践之路”系列的第四篇文章，从单体架构的弊端引入微服务，结合领域驱动的概念介绍了如何做微服务划分、设计领域模型并展示了整体的微服务化的系统架构设计。结合分层架构、六边形架构和整洁架构

《领域驱动设计(DDD)实践之路(二)：事件驱动与CQRS》分析了如何应用事件来分离软件核心复杂度。 这是“领域驱动设计实践之路”系列的第三篇文章，分析了如何设计聚合。聚合这个概念看似很简单，实际上有很多因素导致我们建立不正确的聚合模型。本文对这些问题逐一进行剖析。 聚合这个概…

《领域驱动设计(DDD)实践之路(一)》 主要讲述了战略层面的DDD原则。 这是“领域驱动设计实践之路”系列的第二篇文章，分析了如何应用事件来分离软件核心复杂度。探究CQRS为什么广泛应用于DDD项目中，以及如何落地实现CQRS框架。当然我们也要警惕一些失败的教训，利弊分析以后…

领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网…

软件是对真实世界的模拟，真实世界往往十分复杂 人在认识真实世界的时候总有一个从简单到复杂的过程 因此需求的变更是一种必然，并且总是由简单到复杂演变

它是一种非常方便的方案，可以帮助你解耦你的代码。让层、模块和服务尽量独立。不仅可以独立发布、部署，还可以让你从一个项目迁移另一个项目的时候也更加容易。

随着我们解决的场景越来越专业化和复杂化，大型SPA应用的流行，前端承担的职责越来越多。代码的质量和系统的完整性越来越难把握。很容易导致迭代着迭代着发现代码改不动了。最后只能新起炉灶，重新开发。归根到底在于复杂度的失控，本文会尝试分析其中的问题以及从前端如何应用领域模型开发的角度…

注意这不是大笑表情包，DDD（domain-driven design-领域驱动设计）,大部分前端接到需求的时候都在思考这个原型我要怎么实现某块功能细节（用哪个UI库、该怎么写），即使不了解业务也一样可以开发，通常也能完成工作，这种情况称为 ——「面向功能编程(没有思考的前端资…