先说下传统系统设计,大部分从数据库开始–自底向上的设计,这种设计会使系统的设计受到数据库的影响,会有比较大的局限性,比如说:数据库仅有数据,没有行为,而对现实世界的描述则会更加抽象,更加远离业务.开发团队通过与产品或客户的沟通,直接设计表模型,由于会受到沟通的效率的影响,客户不懂技术,开发从技术角度思考,整个沟通过程则会有较大的信息损失,所设计出的表模型则很可能面临后期业务变动的挑战.导致系统的成败主要取决于架构师在那个领域的业务水平而不是技术水平.
而DDD是采用自定而下的设计,战略设计时业务为王,不再受到技术的局限性(我想可能跟现在技术的发展有关系,极大丰富的底层技术框架,使得技术选型更加自由),设计过程中,需要业务专家(不用懂技术,比如客户和产品等)和开发团队一块仅仅从业务的角度分析需求,不要受到任何技术的局限性,采用事件风暴(类似头脑风暴)的方式,讨论整个系统面临的各种用户场景,整个系统提供的各个功能模块,做业务上的归集分类分级,在讨论过程中,各个团队(客户 产品 开发 测试 运维 交付)逐渐统一语言(同一个限界上下文中),使得业务场景更加清晰的被描述和归纳分类出来,在整个沟通中更加有效率,更加准确,后续维护阶段的持续交付迭代都将由此而获益.
简单来讲就是要大家在设计阶段,不要受到技术实现的影响,统一名词概念,确保各个团队,针对同一个名词在说的是同一个事情.
摘自：https://zhuanlan.zhihu.com/p/351162895
领域驱动设计关心的是业务中的领域划分（战略设计）和领域建模（战术设计），其开发过程不再以数据模型为起点。而是以领域模型为出发点。它更加关注业务语义的显性化表达，而不是数据的存储和数据之间的关系。这是“领域驱动设计”和“数据驱动设计”之间显著的区别。
DDD鼓励我们接触到需求后第一步就是考虑领域模型，而不是将其切割成数据和行为，然后用数据库实现数据，用服务实现行为，最后造成需求的首尾分离。DDD会让你首先考虑业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同，导致编程世界观不同。
