Architecture on Website of SauceWu

Flutter K线系统拆解（一）：架构分层与领域模型

Thu, 20 Mar 2025 12:30:00 +0900

Flutter K线系统拆解（一）：架构分层与领域模型

K 线在 demo 阶段通常不难，难的是进入真实交易场景之后的长期维护。
一旦业务进入高频迭代，常见问题很快会暴露出来：主题体系耦合、模式分支散落、改动范围不可控、扩展成本越来越高。

这一篇只讲架构层面的核心问题：
如何把 K 线从“能画出来的组件”做成“可长期演进的系统”。

一、推荐的系统分层

一套可维护的 K 线实现，通常至少要有这几层：

入口与装配层：图表 widget 生命周期与运行时状态
SDK 抽象层：主题、国际化、事件、屏幕适配等外部能力
数据与指标层：行情实体、指标结果、计算引擎
渲染核心层：坐标、可视区、渲染器管理
渲染阶段层：背景/网格/主图/十字线/叠加层等阶段化执行
策略扩展层：现货、合约等模式差异封装
工具叠加层：订单标记、绘图工具、信息浮层

分层的价值不在“看起来规范”，而在于改动隔离：
新增一个能力时，只需要改对应层，不会把整个系统拖下水。

Clean Architecture 是什么：一篇讲清分层与依赖

Sat, 04 Sep 2021 21:20:00 +0900

Clean Architecture 是什么：一篇讲清分层与依赖

Clean Architecture 常被说成“分层架构”，但它最关键的不是分层本身，而是：
依赖方向必须可控。

一、Clean 想解决什么问题

项目变大后，最容易失控的是依赖关系：

页面直接调 API
业务规则写在网络回调里
换个数据库或 SDK，核心逻辑跟着重写

Clean 的核心目标是：
让核心业务不依赖外部框架和实现细节。

二、经典四层怎么理解

1) Presentation（表现层）

页面、组件、状态管理。
负责“怎么展示”和“怎么交互”。

2) Application（应用层）

UseCase（用例）编排流程。
负责“做什么流程”，不负责“怎么请求网络”。

DDD 是什么：一篇讲清领域驱动设计

Wed, 11 Aug 2021 21:10:00 +0900

DDD 是什么：一篇讲清领域驱动设计

很多人第一次听到 DDD（Domain-Driven Design，领域驱动设计）会觉得它很“玄学”。
其实它解决的问题非常现实：业务太复杂，代码开始失真，团队开始说不清同一个概念。

一、DDD 到底在解决什么问题

当系统进入复杂业务阶段（交易、支付、风控、订单流转），常见问题会出现：

同一个规则在多个地方重复实现
接口字段就是业务模型，改字段就改全系统
“下单”“成交”“结算”这些词，每个人理解都不一样

DDD 的核心目标是：
让代码结构贴近业务结构，让业务语言和代码语言一致。

二、DDD 的核心概念（只记最关键的）

1) 领域（Domain）

你的业务问题空间，比如“交易系统”就是一个领域。

2) 统一语言（Ubiquitous Language）

产品、业务、研发使用同一套术语。
比如 Order、Fill、Position 必须定义一致，避免口头理解和代码实现偏差。