DDD 被过度神话？和MVC区别是什么？
MVC 作为一种架构模式，在软件开发进程中扮演着极为重要的角色。在早期小型项目开发，由于代码量有限，业务逻辑也相对简单，为了快速达成需求，往往会采用一层架构的方式，将所有代码集中在一个文件里进行编写。这种方式在项目初期能够高效地完成任务，满足基本的业务需求。
但随着项目规模不断扩大，业务复杂度持续攀升，一层架构的弊端逐渐显现。代码的维护难度急剧增加，当需要修改或扩展功能时，牵一发而动全身，极难定位和处理相关代码。同时，面对复杂多变的业务需求，一层架构的灵活性和扩展性严重不足，无法有效应对。
正是在这样的背景下，为了找到一种更科学合理的方式来组织代码，提升软件的可维护性与扩展性，MVC 架构应运而生。它通过技术分层，分离代码职责，解决代码组织的清晰性问题，将应用程序分为三个技术层次：
- Model（模型层） ：负责与数据相关的逻辑和操作，例如与数据库的交互和数据处理。
- View（视图层） ：负责界面展示，将数据呈现给用户。
- Controller（控制层） ：负责处理用户请求，协调模型层和视图层之间的交互。
但随着软件行业的发展，渐渐地MVC架构也有了其不足之处。MVC的分层是按照职责来分的，但是它对于某一块的业务，并没有将逻辑抽象到一起，只是将业务拆分成不同的部分来实现
随着项目的发展，每一层的逻辑重复度高，各层的业务互相依赖，没有边界；如果后续项目升级或者改造，那得满世界去查询对应的代码，再改正
在这种背景下，DDD应运而生！
DDD是一种软件设计方法论，核心目标是通过领域模型来解决复杂业务问题。
- 统一语言
- 限界上下文
- 领域、子域、支撑域
- 聚合、实体、值对象
- 分层：用户接口层、应用层、领域层、基础层
其实就是在MVC的基础上，再按业务边界划分，将业务拆分成一个个领域，这样封装领域内的逻辑，统一对外暴露的入口。所谓领域，就是指特定的问题域，用来限定业务边界。所谓的领域模型，就是对业务领域中概念、规则和行为的抽象，通常由领域专家和开发人员共同创建。
DDD的优点：
- 提高可扩展性，强调业务领域的划分和建模，领域之间的解耦降低了系统间的耦合度，有利于未来的功能扩展和新技术引入。
- 支持复杂业务场景，更适合复杂业务场景，通过聚合和领域服务实现多层次业务逻辑的组织，确保代码清晰且易于扩展
- 提高可维护性，将复杂的业务场景划分为简单的领域，降低了领域之间的耦合度，利于代码的阅读和维护
- 增强团队协作，基于业务领域，领域模型与业务需求紧密结合，使开发团队能围绕业务需求展开协作，提高了沟通效率和系统的一致性。
但也需要注意，DDD对开发者经验和领域知识要求较高，开发者需要避免过度设计和降低学习成本。
总的来说，MVC架构侧重于代码的层次划分，凭借清晰的层次结构，能有效提升代码的可维护性与可扩展性，在一些业务逻辑相对简单、对功能迭代速度要求较高的系统中表现出色。
而DDD以业务领域为核心，将重点放在对复杂业务逻辑的梳理、组织与管理上。 在现代复杂业务场景中，DDD 提供了更灵活、更具扩展性的架构模式，使系统能适应不断变化的需求。
感谢阅读，原创不易，如果有所收获的话，别忘了关注我！
