DDD这个理念早就不陌生了，这几年也有越来越多的公司去尝试实践。
先简述下DDD，领域驱动设计（Domain-Driven Design，简称DDD）是一种软件开发方法，它强调在软件开发过程中关注业务领域的需求和约束。通过将业务领域的概念、规则和逻辑映射到软件系统中，DDD可以帮助开发人员更好地理解业务需求，提高软件的可维护性和可扩展性。
领域驱动设计的主要特点包括：
- 领域模型：领域驱动设计的核心是领域模型，它描述了业务领域中的概念、实体、值对象、聚合根等概念及其之间的关系。领域模型通常由一组领域专家根据业务需求和约束来定义。
- 限界上下文：领域驱动设计将系统划分为多个限界上下文，每个限界上下文代表一个特定的业务领域。限界上下文之间的边界清晰明确，以便于理解和管理。
- 领域事件：领域驱动设计中，领域事件是表示业务领域中发生的事件或操作的类。领域事件通常包含一些元数据，如事件类型、源实体、目标实体等。
- 领域服务：领域驱动设计中，领域服务是封装了领域逻辑的业务逻辑组件。领域服务可以用于处理跨限界上下文的操作，例如数据的持久化、远程调用等。
- 领域仓库：领域驱动设计中，领域仓库是负责访问领域模型的数据访问层。领域仓库通常使用实体关系数据库或其他持久化技术来实现。
通过以上特点，领域驱动设计可以帮助开发人员更好地理解业务需求，提高软件的可维护性和可扩展性。同时，领域驱动设计也有助于降低软件系统的复杂性，提高开发效率。
思考
DDD和非DDD的开发流程有什么区别？
常规开发流程并是开发分析了当前的业务之后，在某个业务表里面加个字段，然后写mapper，然后service，然后controller暴露出来，而DDD的开发流程是经过领域专家分析，分析业务属性是属于哪个领域，改造该领域使之成为最符合业务当前场景和以后场景的。
谁来设计DDD？
领域专家。
谁会是领域专家？公司内部或者业内在技术和业务领域有一定影响力的人。
谁能保证这个关键人物他的设计就是一定是对的？
没有谁能保证他的设计就是一定是对的，他自己可能也不一定有把握说自己的设计一定是对的。只能说在当下，他拍板的设计是相对正确的，可能他的技术相对深厚，业务相对深厚。但也可能他的title在公司里相对高，在业界影响力较高，或者说他和老板的关系更近。
未来是变化的，技术是这样，业务也是这样，没有谁能够保证他设计的这一套会长效的，持续的正确。至于谁来保证是不是对的，交个市场去验证吧。
看清楚自己当前的角色定位
如果是敲代码的，他们设计好，你照着做就行。
如果是做决策的，决策好就行，并为此决策负责。明确风险，把控进度，上游预算，下游实现。
如果是老板，为最后的设计结果买单的，就去信任那个关键人物就行了。
