René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"面向领域驱动设计 ——  Domain Driver Design","articleBody":"- 业务模型即为类对象，通过对对象的封装实现对业务的封装，封装的原则就是单一责任。\r\n- 业务的梳理，可区分业务的主线与支线。简化业务复杂度，增加业务的拓展性。\r\n- 业务模型与数据持久化是松耦合的关系，他们之间更像是一种订阅关系\r\n- 业务的拓展，可通过事件与消息模式解耦\r\n    - 事件与消息区别\r\n        - 事件：事件通常发生在程序系统内部，发生在进程的内部。事件订阅者与发起者可以不在同一个事务内，各个订阅者相对独立。\r\n        - 消息：消息队列通常是异步的，通常发生在不同的进程里。\r\n- 可视化与UML，可视化是为了便于理解，为了进一步的优化模型\r\n- 防腐层与Repository的区别，他们都采用接口隔离设计，防腐层是对其他模块防腐，更像是一种提供API的能力，而Repository是内部防腐，其实是隔离业务模型与基础设施的一种抽象。\r\n\r\n业务分类：\r\n\r\n1. 主动业务，业务由自己可控，例如自己有一个订单对象，你通过订单对象可以完成对订单的创建与变更。\r\n2. 被动业务，业务的控制是由其他资源控制的，例如同样是订单的操作，但是你需要调用其他服务的api实现，而不是由自己的业务来实现。\r\n\r\nPS：\r\n  针对这两种业务，是都可以实现业务模型的自控的。这里主要讨论的是被动业务模式，在这种情况下开发的过程中，容易被第三方的提供能力所束缚，例如受限于他提供的接口顺序与字段要求，容易让自己的业务模型变成了调用服务的工具类，从而失去了模型的意义。对应这样的场景，提供两个建议：  \r\n   1，我们可以把第三方服务看做成数据库服务，这样你的业务模型与第三方服务交互的过程就变成了是由Repository完成的持久化过程了。  \r\n   2，为了应对第三方服务层面的设计（如接口顺序、字段限制）问题影响到业务模型，可以在第三方服务的基础设施上做适配器，不要让第三方服务的设计问题腐蚀到你的业务模型。  ","author":{"url":"https://github.com/xlorne","@type":"Person","name":"xlorne"},"datePublished":"2022-07-21T06:44:19.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/14/springboot-framework/issues/14"}