DDD（Domain-Driven Design）与传统的OOA/D（Object-Oriented Analysis and Design）有以下几个不同点：
- 领域驱动设计注重建立一个通用语言，使得业务专家和技术人员之间能够沟通协作，在业务问题的解决上更加高效。而传统的OOA/D则更加强调分析模型与设计模型的构建。
- DDD更加注重对领域模型的抽象，将领域内的各元素进行拆分和组合，从而形成每一个子领域下的完整模型，帮助开发人员在实现过程中保持一致性。而OOA/D则更加偏重于将对象和类抽象出来，并且通过组合与继承完成系统构建。
- DDD更加注重领域模型的演化，将其视作一个不能静止的东西，随着业务需求的变化而不断优化和完善。而OOA/D则更加关注系统的可扩展性以及代码的重用性。
- DDD更加注重业务特性的发现，将领域模型中的各种约束和规则表达出来，从而为后期的开发工作提供了基础。而OOA/D更加注重面向对象的编程思想，强调封装、继承和多态等概念。
- 总的来说，DDD关注业务领域本身，以及在这个领域内发现的问题和需求，而OOD则更加关注软件系统本身。DDD通过领域建模和通用语言的建立来解决问题，而OOD更加注重针对系统性能和架构的优化。
通过DDD分析业务的流程和OOA/D的流程有什么区别？
- 划分领域模型
DDD强调对业务领域进行抽象和建模，将复杂的业务逻辑划分为多个子域（Sub-Domain），然后针对每一个子域去设计相应的领域模型。而传统的OOA/D则更加注重对整个系统的分析与设计。
- 定义通用语言
在DDD中，定义通用语言（Ubiquitous Language）是非常重要的一步，在此过程中，开发人员必须积极与业务专家沟通，并将其理解的业务术语和规则与代码实现相对应。而传统的OOD则更多地关注于对象、类、数据等方面的建模。
- 实现领域模型
在DDD中，领域模型是核心，程序员需要将领域模型转换成代码实现，保证代码和领域模型的一致性。而在传统的OOD中，程序员需要根据分析模型进行相应的编程实现。
- 在领域里驱动代码实现
在DDD中，领域模型是代码实现的主导方向，程序员和业务专家共享领域模型，这样可以有效地避免因为业务专家和程序员语言不通而导致的需求理解不清的问题。而传统的OOA/D中，分析模型和设计模型是主导方向。
总之，DDD注重业务领域本身，强调从实际业务出发进行领域建模和通用语言的建立，将领域模型和代码实现保持一致性；而传统的OOA/D则更加侧重于对系统的架构、数据的组织等技术层面的考虑。
最后
从个人的实际应用场景，其实从传统的面向对象转到DDD有很大的学习成本，而且对于DDD来说需要对业务的理解有一定的深度和抽象能力。比如spring的mvc三层转到DDD的写法和用法，可能100家公司有101种理解和拆分方法，而且DDD有很多新的概念，当然也不是说DDD不好，要看实际场景，比如用DDD来拆分业务和分析业务，边界是一个很不错的一种工具。当然一切还是需要从实际出发~没有好坏，只有适不适合~
