DDD领域驱动设计

DDD是领域驱动设计(Domain-Driven Design )的简称，DDD是一种分析设计建模方法，它倡导统一语言，提出了实体和值对象以及聚合根等概念，借助DDD我们能够在结构理清需求中领域模型。

服务器后端的发展历程：
1、UI+DB，两层架构。
2、UI+Service+DB，多层SOA架构，MVC三层架构成为主流。
3、DDD+SOA微服务的事件驱动，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。

DDD强调的，数据对象由之前的贫血模式，改为充血模式。由之前的单纯属性get/set，增加对象本身的功能，行为。

领域驱动设计，都离不开软件工程，面向对象的设计思想，高内聚低耦合。

整洁的分成架构如图：

领域划分是重点：
，微服务粒度拆分不宜太细，如大数据领域业务方向可以继续向下划分，如指标、开发平台、数仓、调度中心、集成平台等，每个小方向2-3个人，每个业务方向申请1-2个微服务，流程复杂场景申请2个，服务拆分粒度出于几点考虑

1个微服务2-3人负责开发和维护，小组内一个主 owner，剩余研发同学负责打配合，他们是可以参与架构设计、需求讨论的，基本能保证每个研发对系统能深入了解，但要有人牵头对整条业务线负责；
2-3人组是相互 backup 的，假设组内有1个同学请假，另外两人顶上不至于出现单点故障，出问题找不到人的情况；
业务不稳定，迭代多的情况建议大家采用上述2个方案，到业务稳定期微服务代码改动不多并不需要这么多研发了，1个研发维护1个甚至多个微服务都是可以的。