一 软件项目通病
-
开发人员过于热衷技术，思想上更希望通过技术来解决问题，而不是深入思考设计问题，导致使用了新技术，但是设计一直得不到修改，带来更大的问题。
-
太过重视数据库，多数解决方案都是围绕数据库和数据模型，而不是业务流程和运作方式
-
对于业务目标命名的对象和操作，开发人员没有给予应有的重视，导致交付的软件和真正的业务模型产生分歧
-
业务人员花费大量时间闭门造车作出很奇葩的需求，只有一小部分能被开发采用，其余时间都在争辩。
-
频繁而又要求精准的项目估算会占用大量的时间和精力，开发人员使用任务卡而不是考虑周详的设计，导致最终产生一个不恰当的业务模型，且项目延期。
-
数据库查询会时常出现中断，延迟，死锁等问题，阻碍用户执行
时间敏感型的业务操作 -
项目中存在错误的抽象级别，开发人员希望通过借助过度概括的方案满足所有当下臆想出来的未来需求，而不是实际解决具体的业务问题
-
当一个服务执行操作时，直接调用另一个服务造成紧耦合，会经常破坏业务流程和未达成一致性的数据
二 领域驱动设计概念
领域驱动设计常以战略设计与战术设计来将整个领域展现的淋漓尽致，其作用范围既面向业务也面向技术。从战略角度(个人更喜欢称其为上帝视角)去规划系统、划分领域。而从战术角度则从技术层面来指导我们该如何去设计。 通过领域驱动设计可以解决项目中的一些通病。
三 基本组成
DDD主要关注如何在明确的限界上下文中创建通用语言的模型.
- 限界上下文
限界上下文是语义和语境的边界，限界上下文中的组件可以理解成
解决方案空间,就是真正实施解决方案的地方，这些解决方案被识别为核心域。 - 通用语言
团队在限界上下文中发展了一种语言用于表达其边界内的软件模型，这一语言由在该限界上下文中开发软件模型的每个团队成员使用，就是
通用语言 - 核心域 当限界上下文被当做组织的关键战略举措进行开发时，即被称之为核心域
