高内聚，低耦合：单一职责原则、依赖反转原则、开放封闭原则
- 构建领域地图（边界）
a. 在DDD中推荐了事件风暴会议这样的具体形式，也强调了统一语言的理论模型。
b. 针对各个核心环节，优先构建单元测试案例，从而形成一些TDD测试驱动设计的实践场景。
c. 领域并不是天然存在的，这需要依赖于软件团队对软件需求的合理分析。并且分析的过程，即不能太过偏向于真实的业务领域，也不能太过偏向于极度抽象的技术领域，需要在整个项目团队内形成共识，然后通过初步抽象的通用语言将设计结果固化下来。 - 使用四层架构巩固领域基础（包结构）
application domain xxx adaptor interface entity infrastructure repository service - 划分限界上下文，巩固领域划分（DDD落地实践的关键）
a. 传统MVC设计方式中，强调的是技术隔离，而并没有从业务上的限界上下文边界，所以，逻辑边界是混乱的。
b. 领域应该是足够内敛的，每个领域内的业务能力是与当前领域的知识语境紧密相连的。一个领域想要调用另外一个领域的业务能力，只能通过对方暴露出来的业务能力进行协作，而不能去干预对方领域的实现细节。所谓的单体架构、微服务架构、甚至包括MQ事件驱动架构，在DDD的视野中，都是领域之间的不同协作方式而已，对领域内部都是没有影响的。
c.
- 单体架构优先（SPI）
a. 越是复杂的项目，就越应该重视单体架构的快速验证和快速试错，这对于提高复杂项目的运行效率是非常重要的
b. 然后将单体架构中的关键领域拆分成微服务（比如SPI切换为Nacos，由于有防腐层，所以只需要切换抽象接口的实现类即可）
