- DDD(领域驱动设计)事件⻛暴方法在仪表盘配置中的具体应用是什么?
核心答案关键词:
- 领域建模的团队作用
- 事件⻛暴(Event Storming) 优缺点和替代方案
- 需要需求/代码映射对团队知识的打造
- 通过解耦模型层与请求层,如何提高系统的扩展性和维护性? 核心答案关键词: MVC 模式、分层架构、数据访问层与业务层分离、接口抽象、依赖注入
- 在前端中如何实现高效的状态管理?在该项目中是如何使用 Redux 的?
核心答案关键词: Redux 状态管理、store、reducer、actions、middleware、异步操作管理
- Redux 是依赖注入不完善的无耐之举
- 仪表盘配置重构中,如何通过面向对象设计提高代码的可扩展性和复用性? 核心答案关键词: 面向对象设计、类与接口、继承与多态、组合而非继承、模块化
- 标准化测试工序中,如何加速知识传递和团队协作? 核心答案关键词: 测试驱动开发(TDD)、单元测试、文档化流程、AI 技术辅助、自动化测试
- 如何处理大型数据集的渲染,避免性能瓶颈? 核心答案关键词: 虚拟滚动、懒加载、数据分⻚、批量渲染、惰性计算
下面的只有部分有做过，不是很好写
- 如何设计和实现仪表盘的数据可视化与图表展示? 核心答案关键词: 数据绑定、ECharts 配置、动态数据渲染、图表联动、性能优化
小公司没那么多的钱去弄这个，一般用于培养人写测试的能力，而不是直接生成测试，在上面的标准化测试工序中完成
- 如何使用 AI 技术提高测试效率,并保证测试的稳定性? 核心答案关键词: AI 测试辅助、自动化回归测试、智能识别变化、测试用例生成、bug 预测
软件开发的核心难度就在于处理隐藏在业务知识中的复杂度。
想要处理这种复杂度，首先需要打破业务和技术之间的知识壁垒（统一语言），如果双方对彼此的知识域有基础的了解（模型），那么知识传递与沟通的效率就可以变得更高。
其次，对于复杂的问题，需要快速的反馈周期（提炼知识的循环）试错。复杂的问题也就是没有现成答案的问题，只能快速试错。双方参与到彼此工作中，在流程中就可以给予对方反馈，而不是等到产生最终结果之后再评价。那么反馈速度自然就更快捷，同时浪费（研发时间、无效代码）也更少。
因而，让业务方与技术方参与到对方的工作中，就在双方之间带来了更好的协同效应（Synergy Effect），也就是 1+1 > 2 的效果，这正是领域建模最吸引人的地方。
领域建模中，最常见的就是事件风暴法，从实践经验上来讲，事件风暴可以说是“一学就会，一用就废”的方法，因为它会带来大量的思维分散，但是主导者却未必有能力将思维收束。在仪表盘配置的讨论过程中能成功，是因为仪表盘配置的 user story 取自于遗留系统，互联网上也有相关的功能案例可参考，发散性并不会特别强。那能不能直接从收束侧进行讨论呢？有的，我们做任何功能，无非就是“拿人钱财，替人消灾”。这种情况下，完全可以通过履约建模法来映射我们的真实业务流程。
领域驱动设计鼓励我们通过领域模型（Domain Model）捕捉领域知识，使用领域模型构造更易维护的软件。这样就带来了诸多好处
- 以模型反应软件实现（Implementation）的结构，这样新人只要理解了模型，就能大致理解代码的结构。
- 以模型为基础，形成团队的统一语言（Ubiquitous Language），方便研发在讨论需求时更容易明白需要改动的代码，从而更好的评估风险与进度。
- 以模型用于抽象知识，相比代码本身有着更低的传递成本。在现在强 ai 的 token 比较贵的情况下，DDD 可以说是一个 更加 LLM friendly 的方式。