数据流是前端一直以来都存在的一个问题，我们项目沉淀了一套最佳实践。

无论我们使用单体、SOA、微服务、中台或者其他架构，都需要解决如何组织代码这个问题，DDD 并不是一个技术，而是指导我们组织代码的一种思想，这种思想也并不是凭空出现的。

领域驱动设计（Domain Driven Design - DDD）起源于2004年Eric Evans出版《领域驱动设计》，相比于在国外IT圈享有盛誉且行之有效不同，国内IT圈了解DDD的人很少，落地实践的少之又少。最近几年随着微服务架构的普及和中台的兴起，DDD也成了各大技术论坛和微信公众号文章里经常谈起的话题。

DDD的热度是起来了，但业界介绍DDD的资料大多偏理论，缺乏生产项目可借鉴的实践经验。因此大多人读了很多DDD材料后还是一脸懵，怎么衡量DDD带来的价值？老板能同意搞DDD吗？什么样的业务和团队适合DDD？DDD跟互联网强调的小步快跑快速迭代能搭吗？如果要实践DDD产研团队都要做些啥？研发写代码跟平时有什么不一样？本文结合百度爱番番产研团队在过去一年多经历的从探索、推广到全面落地DDD的过程，尝试回答上述问题，力求给大家带来一些借鉴意义。

DDD存在战略设计和战术设计之分，过度地强调DDD的技术性将使我们错过由战略设计带来的好处。因此，在实现DDD时，我们应该将战略设计也放在一个重要的位置加以对待。

本文根据具体实例详细描述了DDD 落实到数据库设计的整个过程​。

在一个软件项目里除了技术层面的这部分，我们最主要的事情是实现业务。实现业务其实是在实现所在业务领域中所需要的业务。技术也是一个领域，称之为技术领域。领域驱动设计中的领域是指的业务领域。

大多数的技术人员对技术领域中的知识比较感兴趣（狂热），因为这能够使得自己在技术方面有一些前沿性和探索性的实践。然而对于业务领域中的知识就显得比较暗淡一些。

本文主要讲解领域驱动设计如何为爱奇艺打赏业务创造价值。

领域建模的方法有多种，甚至关于领域模型本身的定义也有一些模糊之处。不同的方法论和流派思路大体相似，在细节上还有一些区别。不过条条大路通罗马，他们没有对错之分。

将中台和 DDD 视作一种设计思想和方法，吸收它的精髓，与时俱进。并结合企业文化和团队技术特点，有所取舍，灵活运用才是王道！

什么是对内 DDD，对外 API 呢，这个是我们业务研发领域内使用 DDD 作为领域设计、微服务设计的理念的实践原则，领域间使用 API 进行交互的一种通俗易懂的说法。

在一个DDD架构设计中，领域层的设计合理性会直接影响整个架构的代码结构以及应用层、基础设施层的设计。但是领域层设计又是有挑战的任务，特别是在一个业务逻辑相对复杂应用中，每一个业务规则是应该放在Entity、ValueObject 还是 DomainService是值得用心思考的，既要避免未来的扩展性差，又要确保不会过度设计导致复杂性。今天我用一个相对轻松易懂的领域做一个案例演示，但在实际业务应用中，无论是交易、营销还是互动，都可以用类似的逻辑来实现。

万字长文，结合电商支付实际演练领域驱动设计，DDD看这篇就够了

从单体架构的弊端引入微服务，结合领域驱动的概念介绍了如何做微服务划分、设计领域模型并展示了整体的微服务化的系统架构设计。结合分层架构、六边形架构和整洁架构的思想，以实际使用场景为背景，展示了一个微服务的程序结构设计。

对于服务拆分的逻辑来说，是先设计高内聚低耦合的领域模型，再实现相应的分布式系统。服务的划分有一些基本的方法和原则，通过这些方法能让微服务划分更有操作性。

本文主要介绍了领域建模在有赞美业客户领域的思考与实践。

本文将结合实际的基于DDD思想的酒店报价重构项目，从DDD推荐的战略设计、战术设计、系统实现三个核心阶段讲解DDD在整个过程中的巨大作用，同时涉及各个阶段目标及产出，希望这些实践能对读者有一定的指导作用。