​使用DDD领域驱动设计的思想对福利中心（用于同事之间互赞互动）进行开发，在自己的业务中落地微服务。

最近看了一本书《解构-领域驱动设计》，书中提出了领域驱动设计统一过程（DDDRUP），它指明了实践 DDD 的具体步骤，并很好地串联了各种概念、模式和思想。因此，我对书本内容做了梳理、简化，融入自己的理解，并结合之前阅读的书籍以及实践经验，最终形成这篇文章。希望可以帮助大伙理顺 DDD 的各种概念、模式和思想，降低上手 DDD 的门槛。

2020年疫情对旅游行业影响特别大，公司层面做了组织架构调整，酒店业务侧发生了巨大的变化，新的业务团队在推进一些实际需求时遇到了新的产研效率问题，主要体现在产品每次要和多个技术团队合作、整体技术架构与业务出现脱节。

结合之前 DDD 落地的成功经验，酒店技术侧于2021年中旬主动发起了一次基于 DDD 思想的技术架构战略调整，涉及组织架构调整、系统架构调整等，并制定了一些核心技术方案的标准，本次重点介绍这次战略调整的确认及落地过程。最后基于这次战略调整，看康威定律及 DDD 思想发挥的作用。

‍本文旨在探讨如何从容应对复杂性。

本文从编程实践的层面，对领域驱动开发做一些简单的介绍。

公司采购了XX作为资金平台，并计划将所有的资金划拨操作转移到XX；当前每刻报销也依赖用友进行付款；所以需要将每刻和用友的交互逻辑以及支付逻辑迁移到业财进行管理。

在与很多微信朋友讨论 DDD 落地的时候也给出了一些自己的见解，但是却很少有机会亲手尝试下如何解决一些现实场景，因此借着 DDDinAction 的项目通过权限平台的代码实战将自己的思路一点点落地和完善。

当然也有很多人希望找到一个 DDD 实战项目代码，因此在迭代了一些 codeMaker 的功能特性之后便把 infosys-plat 的 infosys-auth 权限平台来真正落地一把，看一下用 DDD 的方式如何写出更好的代码。

本人是作者对工作中现有业务的领域驱动重构得出的心得,还有在领域驱动模型上进行需求迭代的经验讲解。

技术债偿还一直是软件开发绕不开的话题，如何能够让技术重构既还了过去的债又能为将来业务发展产生持续的收益？本文介绍爱番番沟通产研团队一次业务和技术双赢的技术重构经历。既有从现象到本质的思考方法论，也有DDD、微服务架构、云原生架构的落地实操。

本文尝试使用DDD来介绍有赞信贷核心系统的设计过程，让大家对DDD的落地有一定的了解。

As software design evolves, so do the thought processes behind the design decisions we make as engineers. Some of these development practices are widely known and talked about, such as Test-Driven Design, where changes to code are made in programmatic tests before they’re implemented in actual business logic.

These design practices are helpful for our future selves and for our teammates, because they help us keep our code well-maintained and easily extendable. How do these practices help external audiences, or audiences that aren’t as technical, understand our code? When designing a new API or making impactful changes to an existing API, a Documentation-Driven Design approach can be helpful in guiding the design decisions you make, too.

随着业务的不断发展，我们发现自己的系统开始变得有点臃肿，为了减少复杂性，我们尝试借助DDD来改善我们的系统。本文记录了自己对DDD的理解和实践过程，欢迎大家一起探讨。

任何一套业务架构都可能存在一定的历史问题，这是业务在不同阶段做技术选型必然出现的状况，如何用新的、合适的架构思想做恰到好处地改造，则是架构师们的必备能力。本文是 Keep 利用 DDD 改造电商供应链系统的一次精彩实战，InfoQ 架构头条独家分享，以供大家参考交流。

通天塔后端团队经过数年的逐步探索，摸索出了一条可扩展、高可用、可维护、部署灵活、多租户支持的通用版架构之路。

架构这个词源于英文里的“Architecture“，源头是土木工程里的“建筑”和“结构”，而架构里的”架“同时又包含了”架子“（scaffolding）的含义，意指能快速搭建起来的固定结构。而今天的应用架构，意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在应用开发中架构之所以是最重要的第一步，因为一个好的架构能让系统安全、稳定、快速迭代。在一个团队内通过规定一个固定的架构设计，可以让团队内能力参差不齐的同学们都能有一个统一的开发规范，降低沟通成本，提升效率和代码质量。

在做架构设计时，一个好的架构应该需要实现以下几个目标：

• 独立于框架：架构不应该依赖某个外部的库或框架，不应该被框架的结构所束缚。
• 独立于UI：前台展示的样式可能会随时发生变化（今天可能是网页、明天可能变成console、后天是独立app），但是底层架构不应该随之而变化。
• 独立于底层数据源：无论今天你用MySQL、Oracle还是MongoDB、CouchDB，甚至使用文件系统，软件架构不应该因为不同的底层数据储存方式而产生巨大改变。
• 独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应该随之而大幅变化。
• 可测试：无论外部依赖了什么数据库、硬件、UI或者服务，业务的逻辑应该都能够快速被验证正确性。

这就好像是建筑中的楼宇，一个好的楼宇，无论内部承载了什么人、有什么样的活动、还是外部有什么风雨，一栋楼都应该屹立不倒，而且可以确保它不会倒。但是今天我们在做业务研发时，更多的会去关注一些宏观的架构，比如SOA架构、微服务架构，而忽略了应用内部的架构设计，很容易导致代码逻辑混乱，很难维护，容易产生bug而且很难发现。今天，我希望能够通过案例的分析和重构，来推演出一套高质量的DDD架构。

对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战，无论是 94 年 GoF 的 Design Patterns ， 99 年的 Martin Fowler 的 Refactoring ， 02 年的 P of EAA ，还是 03 年的 Enterprise Integration Patterns ，都是通过一系列的设计模式或范例来降低一些常见的复杂度。但是问题在于，这些书的理念是通过技术手段解决技术问题，但并没有从根本上解决业务的问题。所以 03 年 Eric Evans 的 Domain Driven Design 一书，以及后续 Vaughn Vernon 的 Implementing DDD ， Uncle Bob 的 Clean Architecture 等书，真正的从业务的角度出发，为全世界绝大部分做纯业务的开发提供了一整套的架构思路。