leijmdas的专栏

第三代规则引擎开发指导说明书--通用引擎服务2024年3月20日 培训大纲规则引擎是通用域的动力驱动中心，目前规则引擎支持场景可以有，只要是通用的可以放在通用域，可以使用规则引擎实现： 规则配置： 规则引擎实现统一配置，配置应用范围依据主体 ，主体类型+Id；平台商户成员平台是通用的策略，商户自己配置，未配置找平台成员可以自己配置，未配置找商户，商户未配置找平台规则计算或者使用依据客体：客体类型+Id。Object_id实体记录idO

目录项目中心, 项目流转类别权限用户描述用户个人用户可以使用平台所有服务，但是没有公司属性，在平台上既可以是甲方也可以是乙方普通注册就可以使用，需要个人认证公司用户公司管理员可以使用平台所有服务，可以进入公司管理进行操作注册时需要有公司工商资料，可以邀请别人加入自己创建的公司公司员工不能使用公司管理相关功能由公司管理员邀请进入公司角色甲方发布需求，终止洽谈，终止合作需求更改发布需求方，可以选择乙方进行洽谈，合作乙方乙方负责人申请洽谈，终止洽谈，终止合作。

其中创建docker还是比较简单 k8s挺复杂不过有kubesphere安装：√。测试是你成为高阶程序员的阶梯 也是成为架构师的必须。关于需求很多人做过但不知所云比如做平安华为的项目。但说不出很丢分 技术架构也说不出。甚至可以说测试驱动是一种学习方法。要知道需求架构相互证明互为表里。指开发测试主要是单元测试。

首先，我们从容器技术谈起，在容器技术之前，大家开发用虚拟机比较多，比如vmware和openstack，我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑（Linux），子电脑之间是相互隔离的，但是虚拟机对于开发和运维人员而言，存在启动慢，占用空间大，不易迁移的缺点。举一个我亲身经历过的场景吧，之前在vmware中开发了一个线下平台，为了保证每次能够顺利使用，我们就把这个虚拟机导出为OVF，然后随身携带，用的时候在服务器中部署，这里就充分体现了虚拟机的缺点。关键在于该服务可以在自己的程序中运行。

单独的存在,或者说它单独存在是没有意义的。它必须归属于一个或多个实体。是将领域实体对象聚合，所以实体表如帐户表都可以设计成。情况下领域实体存贮性能排序为。以下关于es、db描述不正确的是。一张宽表，这样能提高效率。据库>es>redis缓存。答： 1 4 5 6。

参考《R-D-010-ZHX1703-系统用户与权限管理需求规格说明书》参考《R-D-014-ZHX1703-统一任务消息需求规格说明书》参考《R-D-020-ZHX1703-通用工作流-需求规格说明书》参考《R-D-003-ZHX1703-元数据字典需求规格说明书》参考《R-D-003-ZHX1703-元数据字典需求规格说明书》参考《R-D-001-ZHX1703-项目模板管理需求说明书》参考《R-D-015-ZHX1703-金融账务需求规格说明书》工作流模板、工作流任务查询、历史查询。

通过配置页面路由和header获取token,通过配置token获取信息的url,获取用户信息。消息业务类型：Header, body , json object, jsonarray。通过配置接口名单，代理网关拦截接口数据，转发至代理服务脱敏处理。解析消息体中html之body加上div部分，自动生成水印。配置白名单放通部分用户，不做脱敏处理。替换、无效化、对称加密、平均值、隐藏。根据用户：角色配置不同的脱敏策略，消息类型：http、https。用户角色-》接口+消息关系。否，根据配置差异化脱敏。

1. **明确领域边界**：在设计之初，明确不同领域（如前端、后端、数据库等）的职责和边界，确保每个领域都清晰定义了它的接口和协议。2. **定义清晰的接口**：为不同领域之间的交互定义清晰的API接口，包括请求的格式、参数、数据类型以及预期的响应。11. **团队协作和沟通**：鼓励跨领域团队之间的协作和沟通，确保设计决策和变更能够得到所有相关方的理解。15. **法律和合规性**：确保跨领域设计遵守相关的法律法规和行业标准，特别是数据保护和隐私方面的规定。确保采用适当的认证、授权、加密和数据保护措施。

NATS消息服务框架。

15. 设计一个DDD架构的银行账户系统，包括账户管理、交易处理和报告生成等模块，并说明如何通过DDD原则来处理并发和数据一致性问题。领域驱动设计（DDD）的考试题目可以包括理论理解、案例分析、设计模式识别、系统架构设计等类型。12. 选择一个DDD原则，如实体、值对象、聚合等，实现一个小型的DDD模型，并解释其在业务逻辑中的作用。6. 阐述领域事件在DDD中的作用，并给出一个实际业务场景的例子，说明如何使用领域事件。10. 分析一个现有的软件系统，指出其可能违反DDD原则的地方，并提出改进建议。

领域驱动设计（Domain-Driven Design，简称DDD）是一种软件设计方法，它强调以业务领域为设计核心，通过建模来反映业务专家的知识和需求。这些题目覆盖了DDD的基本概念、原则、模式和实践，适合用于学习、讨论或评估对DDD的掌握程度。- 选择一个实际的业务场景，描述如何使用DDD原则来设计该系统的架构。- 列举一些支持DDD的工具和框架，并解释它们如何帮助DDD的实施。- 区分应用服务和领域服务，并解释它们在DDD中的作用。- 列举DDD中常见的设计模式，并解释它们各自的作用。

在DDD中，聚合根（Aggregate Root）是聚合（Aggregate）的核心对象，它负责维护聚合的边界和一致性，并且封装了聚合内部的实体（Entity）和值对象（Value Object）。需要注意的是，聚合根的行为应该保持聚合的一致性。聚合根可以具有行为，这是因为聚合根不仅仅是数据的容器，也是聚合内部行为的执行者。总之，聚合根在DDD中是一个非常重要的概念，它不仅可以包含行为，而且这些行为对于实现复杂的业务逻辑和维护聚合的一致性起着至关重要的作用。

3. **事件传递**：事件发布后，需要传递给感兴趣的订阅者。2. **事件发布**：当领域事件发生时，相应的领域对象（如实体或聚合）负责发布事件。4. **事件处理**：订阅者接收到事件后，需要根据事件的内容执行相应的业务逻辑。1. **事件定义**：首先，需要定义领域事件，明确事件的类型、属性和含义。- **可扩展性**：随着业务的发展，可能需要添加新的事件和订阅者，系统应能灵活扩展以适应变化。- **幂等性**：确保事件处理逻辑的幂等性，即使事件被重复处理，也不会导致系统状态不一致。

3. **清晰的职责划分**：领域服务使得开发者能够更清晰地划分系统的职责，每个服务负责处理特定领域的业务逻辑，这有助于提高代码的可读性和可维护性。1. **服务粒度的控制**：领域服务的粒度应该适中，既不能太粗，以至于无法有效封装业务逻辑，也不能太细，导致服务过多，增加系统的复杂性。1. **业务逻辑的封装**：领域服务将业务逻辑封装在特定的服务中，使得其他组件可以通过简单的接口调用来完成复杂的业务操作。4. **复用性**：领域服务可以被多个客户端共享和重用，这有助于减少代码的冗余，提高开发效率。

在面向对象设计和架构中，聚合根（Aggregate Root）是领域驱动设计（Domain-Driven Design, DDD）中的一个概念，它代表了一组领域对象的集合，这些对象一起形成一个单元，可以被视为一个单一的实体。订单系统需要将订单数据持久化到数据库中。订单实体是聚合根的核心，它包含了订单的所有基本信息，如订单号、客户信息、商品列表、订单状态、支付信息等。在设计订单系统的聚合根时，需要仔细考虑业务需求和系统的复杂性，合理划分聚合的边界，并确保聚合根能够有效地封装和管理订单相关的业务逻辑。

如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的，否则就做成静态的。Java 8 之前我们知道，一个接口的所有方法其子类必须实现（当然，这个子类不是一个抽象类），但是 java 8 之后接口的默认方法可以选择不实现，如上的操作是可以通过编译期编译的。另外，if else（或switch）本身就是一个“变化点”，当需要扩展新的类型时，我们不得不追加if else（或switch）语句块，以及相应的逻辑，这无疑降低了程序的可扩展性，也违反了面向对象的开闭原则。

4. **识别实体和聚合**：在每个子域内，识别实体（具有唯一标识的对象）和值对象（由属性值组成，没有唯一标识的对象），并设计聚合来封装实体和值对象，确保数据的一致性。1. **识别核心业务流程**：首先，需要识别HR系统的核心业务流程，比如员工信息管理、薪酬福利管理、招聘管理、绩效管理等。8. **迭代和调整**：领域和子域的划分是一个持续迭代的过程，随着业务需求的变化，子域的划分和领域模型可能需要调整。6. **考虑通用域和支撑域**：除了核心业务子域，还可能存在通用域和支撑域。

Go实战全家桶之一：GoConfig 实现springboot相同的配置功能 go继承好别扭，组合实现继承可以吗？Go全家桶规划之二： GO依赖注入框架godi之一，实现BEAN工厂，创建单例或者多实例Go全家桶规划之二： GO依赖注入框架godi之二，实现BEAN工厂自动注册Go全家桶规划之二： GO依赖注入框架godi之三，实现BEAN注册容器、 半自动注册Go全家桶规划之二： GO依赖注入框架godi之四，实现BEAN工厂自动注册了, 通过AST获取所有GO文件的结构体信息Go全家桶规划之二：

2. **使用领域事件进行解耦**：领域事件是一种在不同领域之间传递信息的机制，可以帮助实现领域间的松耦合。4. **使用适配器模式**：适配器模式可以用来封装外部领域的接口，使得内部领域可以通过适配器与外部领域交互，而不需要了解外部领域的具体实现细节。3. **避免直接的领域服务调用**：不同领域之间的服务应该避免直接调用对方的领域服务。11. **领域专家的参与**：在设计跨域交互时，领域专家的参与至关重要，他们可以提供深入的业务知识和见解，帮助设计出更符合业务需求的系统。