面向领域驱动设计 —— Domain Driver Design

[xlorne]

• 业务模型即为类对象，通过对对象的封装实现对业务的封装，封装的原则就是单一责任。
• 业务的梳理，可区分业务的主线与支线。简化业务复杂度，增加业务的拓展性。
• 业务模型与数据持久化是松耦合的关系，他们之间更像是一种订阅关系
• 业务的拓展，可通过事件与消息模式解耦
  • 事件与消息区别
    • 事件：事件通常发生在程序系统内部，发生在进程的内部。事件订阅者与发起者可以不在同一个事务内，各个订阅者相对独立。
    • 消息：消息队列通常是异步的，通常发生在不同的进程里。
• 可视化与UML，可视化是为了便于理解，为了进一步的优化模型
• 防腐层与Repository的区别，他们都采用接口隔离设计，防腐层是对其他模块防腐，更像是一种提供API的能力，而Repository是内部防腐，其实是隔离业务模型与基础设施的一种抽象。

业务分类：

1. 主动业务，业务由自己可控，例如自己有一个订单对象，你通过订单对象可以完成对订单的创建与变更。
2. 被动业务，业务的控制是由其他资源控制的，例如同样是订单的操作，但是你需要调用其他服务的api实现，而不是由自己的业务来实现。

PS：
针对这两种业务，是都可以实现业务模型的自控的。这里主要讨论的是被动业务模式，在这种情况下开发的过程中，容易被第三方的提供能力所束缚，例如受限于他提供的接口顺序与字段要求，容易让自己的业务模型变成了调用服务的工具类，从而失去了模型的意义。对应这样的场景，提供两个建议：
1，我们可以把第三方服务看做成数据库服务，这样你的业务模型与第三方服务交互的过程就变成了是由Repository完成的持久化过程了。
2，为了应对第三方服务层面的设计（如接口顺序、字段限制）问题影响到业务模型，可以在第三方服务的基础设施上做适配器，不要让第三方服务的设计问题腐蚀到你的业务模型。

[xlorne]

关于事件与事务之间的关系说明：

• 事件本身不应该同步主业务的事务，即事件对于主业务来说，可成功可失败，成功与失败都不应该强关联主体业务。
• 若需要让主体业务与分支做事务同步的时候，那不应该采用事件机制，而应该直接采用调用的方式实现业务绑定。

[xlorne]

关于Event与Trigger的差异说明：
Trigger与Event差异是,Event是消息驱动性，而Trigger是订阅驱动性。
两者的差异在于，Event是确定了消息而不确定订阅方，而Trigger则是确定了订阅在等待消息触发。

[bestHAI]

👍👍👍