springboot-framework
springboot-framework copied to clipboard
codingapi
springboot领域驱动开发
- 业务模型即为类对象，通过对对象的封装实现对业务的封装，封装的原则就是单一责任。 - 业务的梳理，可区分业务的主线与支线。简化业务复杂度，增加业务的拓展性。 - 业务模型与数据持久化是松耦合的关系，他们之间更像是一种订阅关系 - 业务的拓展，可通过事件与消息模式解耦 - 事件与消息区别 - 事件：事件通常发生在程序系统内部，发生在进程的内部。事件订阅者与发起者可以不在同一个事务内，各个订阅者相对独立。 - 消息：消息队列通常是异步的，通常发生在不同的进程里。 - 可视化与UML，可视化是为了便于理解，为了进一步的优化模型 - 防腐层与Repository的区别，他们都采用接口隔离设计，防腐层是对其他模块防腐，更像是一种提供API的能力，而Repository是内部防腐，其实是隔离业务模型与基础设施的一种抽象。 业务分类： 1. 主动业务，业务由自己可控，例如自己有一个订单对象，你通过订单对象可以完成对订单的创建与变更。 2. 被动业务，业务的控制是由其他资源控制的，例如同样是订单的操作，但是你需要调用其他服务的api实现，而不是由自己的业务来实现。 PS： 针对这两种业务，是都可以实现业务模型的自控的。这里主要讨论的是被动业务模式，在这种情况下开发的过程中，容易被第三方的提供能力所束缚，例如受限于他提供的接口顺序与字段要求，容易让自己的业务模型变成了调用服务的工具类，从而失去了模型的意义。对应这样的场景，提供两个建议： 1，我们可以把第三方服务看做成数据库服务，这样你的业务模型与第三方服务交互的过程就变成了是由Repository完成的持久化过程了。 2，为了应对第三方服务层面的设计（如接口顺序、字段限制）问题影响到业务模型，可以在第三方服务的基础设施上做适配器，不要让第三方服务的设计问题腐蚀到你的业务模型。
数据权限作为管理系统中常用的功能，却没有非常适合的框架。通常在系统的研发过程中，都由研发人员自行控制。无抽象的数据权限设计模式。 springboot-data-permission将解决该问题 产品远景： * 数据权限不仅限于sql数据，需要支持各种数据的权限分离 * 数据权限非功能权限，设计上与功能权限分离。 * 框架可以任何数据均可作为数据资源划分条件，即数据资源可配置。 * 数据资源与数据权限之间可通过数据权限组来配置数据权限，数据权限组为自定义的数据组。如包括：自己、本级别即以下、全部、自定义。 * 所有需要配置的数据权限均会自动创建数据权限关联关系（one-money） * 数据权限的设置可从两个维度设置：1以用户角度配置数据的可见权限。2以资源角度配置数据的可见用户。
做**数据**权限，个人觉得还是**政府类**的比较严格，也比较通用。 数据权限无非以下几种情况，如果能支持，这个权限还是比较好用的。 1. 自己创建的数据 2. 指定部门层级（组织机构） 2.1 向下兼容，审批数据（如：自己权限范围下的部门数据） 2.2向上兼容，通知公告（如：每个人都能看到自己部门的数据，或上一级，上上级发给下级阅读的数据） 3. 指定夸多部门数据，如：领导实际在某个部门下，但是还代管了某个部 3.1 向下兼容，审批数据（如：自己权限范围下的部门数据） 3.2 向上兼容，通知公告（如：每个人都能看到自己部门的数据，或上一级，上上级发给下级阅读的数据）
**Is your feature request related to a problem? Please describe.** A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] **Describe the solution you'd...