MVVM与领域驱动设计综合分析：原则、平台与务实集成

第一部分：MVVM架构模式——关注点分离的研究

本部分将对模型-视图-视图模型（Model-View-ViewModel, MVVM）模式进行全面解构，从其理论基础、优缺点权衡，到其在不同技术平台上的具体实现进行务实的考察。

第一节 MVVM模式的基础原则

本节将为MVVM、其核心组件及机制建立一个严谨的定义，并通过与 предшествующими 架构模式的比较，将其置于历史发展的脉络中。

。1 核心组件解构：模型、视图与视图模型

MVVM模式强制性地在三个软件层之间实现了分离，分别是用户界面（视图）、底层数据（模型）以及连接二者的中间层（视图模型）。


  • 视图（View）：视图是应用的表示层，通常使用XAML等声明式标记语言定义，或在SwiftUI和Jetpack Compose等框架中通过声明式代码构建 。其职责严格限定于数据显示和用户交互的转发。在设计上，视图是“哑”的，对业务逻辑一无所知 。视图通过绑定上下文（
    BindingContext）或类似属性持有对视图模型的引用 。

  • 模型（Model）：模型代表应用的领域数据和业务逻辑 。在纯粹的MVVM语境下，模型对视图模型和视图完全无知。值得注意的是，在许多简单的实现中，一个独立的模型层甚至可能不存在，此时模式的焦点仅在于视图与视图模型的交互关系 。

  • 视图模型（ViewModel）：视图模型是连接视图和模型的中间层 。它负责从模型中准备和暴露数据，并将其转换为视图易于消费的格式（例如，转换数据类型、格式化字符串）。同时，它还通过命令（Commands）来处理用户操作 。视图模型对其绑定的具体视图一无所知，这极大地增强了其可重用性。

。2 绑定机制：MVVM的声明式核心

数据绑定是同步视图与视图模型的核心机制 。这种连接是声明式的，意味着开发者只需指定UI元素的属性与视图模型属性之间的关系，框架便会自动处理同步。


视图模型通常实现一个类似 INotifyPropertyChanged 的接口。当其属性发生变化时，它会发出通知，数据绑定引擎监听到这些通知后便会更新视图 。这种响应式系统消除了在旧模式中常见的大量手动更新UI的样板代码 。数据流可以是双向的（Two-Way Binding），即视图的改变能更新视图模型，反之亦然。这是MVVM与MVC及某些MVP实现的关键区别之一 。

。3 命令：抽象化用户交互

MVVM不直接在视图的代码隐藏（code-behind）中处理UI事件（如按钮点击），而是使用命令模式（Command Pattern）。视图模型暴露类型为


ICommand 的属性，视图中的交互元素（如按钮）则绑定到这些命令属性上。ICommand 接口定义了 Execute 方法（执行的操作）和 CanExecute 方法（决定操作是否可用，常用于自动禁用/启用UI元素）。这种方式将与UI相关的操作逻辑从视图中移出，置于可测试的视图模型中。

。4 对比分析：MVVM vs. MVC & MVP

为了更好地理解MVVM的创新之处，有必要将其与它的前辈进行结构化比较。


  • MVC（Model-View-Controller）：经典的架构模式，其中控制器（Controller）处理用户输入，并协调模型和视图之间的更新。在许多Web实现（被动式MVC）中，视图是无状态的且逻辑很少，而控制器是核心 。在传统MVC中，视图可以直接观察模型。

  • MVP（Model-View-Presenter）：MVP是MVC的演进，其中呈现器（Presenter）扮演着严格中介的角色。视图和模型完全解耦，仅通过呈现器进行通信 。视图和呈现器之间的通信通常通过接口进行双向交互，这使得对视图逻辑的测试更加严谨 。

  • MVVM的关键区别：最主要的区别在于用视图模型替换了呈现器，并使用声明式数据绑定系统取代了呈现器对视图的手动更新 。这使得视图和视图模型之间的连接更加自动化，而非过程化。


这种从MVC到MVP再到MVVM的演进路径，其背后存在一个清晰的驱动力。这一系列架构模式的迭代，本质上是为了不断增强关注点分离，特别是将UI（视图）与应用及表示逻辑（控制器/呈现器/视图模型）隔离开来。这种分离的直接好处是提升了可测试性，因为逻辑部分可以在不实例化或操作复杂UI的情况下进行单元测试。可以说，这一演进过程是对传统UI耦合代码难以测试这一核心痛点的直接回应。


特性

MVC (模型-视图-控制器)

MVP (模型-视图-呈现器)

MVVM (模型-视图-视图模型)

核心耦合

视图可以直接访问模型（主动式MVC），或由控制器完全协调（被动式MVC）。

视图和模型完全解耦，所有交互通过呈现器 。

视图通过数据绑定与视图模型松散耦合；视图模型对视图无知 。

数据流机制

控制器处理输入，手动更新视图和模型 。

呈现器从视图接收事件，从模型获取数据，并手动更新视图 。

声明式数据绑定（单向或双向）自动同步视图和视图模型的状态 。

UI逻辑位置

主要在控制器中，视图也可能包含部分显示逻辑 。

逻辑主要在呈现器中，视图非常“薄”，仅作为接口 。

逻辑完全在视图模型中，视图仅包含声明式UI定义 。

可测试性

较低，因为控制器与UI框架紧密耦合。

较高，呈现器不依赖UI框架，视图可通过接口模拟。

非常高，视图模型是纯代码类，独立于UI，易于进行单元测试 。

第二节 MVVM的批判性评估

本节将超越定义，对MVVM模式进行平衡的审视，探讨其广受赞誉的优势以及在实践中遇到的挑战。

。1 枚举优势

  • 增强的可测试性：这是最常被提及的优点。由于视图模型是一个不依赖任何UI框架的普通代码类，其逻辑可以被轻松、彻底地进行单元测试 。

  • 关注点分离：MVVM强制在UI（视图）、表示逻辑（视图模型）和业务数据/逻辑（模型）之间建立清晰的界限。这种分离使得代码库更易于理解、维护和调试 。

  • 改善协作：这种分离允许UI/UX设计师专注于视图（例如，在XAML中工作），而开发人员则专注于视图模型中的逻辑，从而实现并行开发工作流 。

  • 代码可重用性：单个视图模型可以支持多个视图，促进了模块化并减少了代码重复 。

。2 公认的缺点与固有权衡

  • 复杂性与学习曲线：对于简单的UI，MVVM可能显得“杀鸡用牛刀” 。数据绑定、命令和响应式编程等概念对于不熟悉该模式的开发者来说，可能存在陡峭的学习曲线 。

  • 调试挑战：由于数据绑定是声明式的，并且由框架“神奇地”完成，因此调试起来可能比传统的、控制流明确的命令式代码更加困难 。

  • 样板代码与开销：实现MVVM可能会引入额外的类和代码，特别是在属性变更通知和命令设置方面。尽管现代工具包（如4中提到的Microsoft MVVM Toolkit）旨在通过源生成器减少这种情况。

  • 紧耦合风险：尽管MVVM旨在实现松耦合，但在处理复杂的UI逻辑或难以在视图模型中抽象的平台特定功能时，视图和视图模型之间仍可能出现紧密耦合 。


深入分析可以发现，MVVM的核心机制——声明式数据绑定——本身就是一把双刃剑。一方面，它通过自动化UI同步极大地简化了开发工作，减少了样板代码 。另一方面，正是这种自动化和抽象，使得调试变得困难 。当出现问题时，开发者很难追踪框架在幕后执行的命令式步骤。因此，采用MVVM代表了一种有意识的架构决策：用声明式的便利性（开发更快）来换取明确的命令式控制（调试更易）。对于架构师而言，评估这种权衡是否适合其团队和项目至关重要。

第三节 实践中的MVVM：跨平台实现概览

本节将分析抽象的MVVM模式如何在Web、移动和桌面等主流平台的框架中被具体实现，并揭示其在不同生态系统中的细微差别和适应性变化。

。1 Web开发：“MV-Whatever”家族

JavaScript框架在很大程度上采纳或改编了MVVM的原则。


  • Vue.js, Angular, Ember.js：这些框架被明确指出采用了MVVM模式或与其非常相似 。它们具有强大的数据绑定能力和清晰的模板（视图）与组件逻辑（视图模型）分离。

  • React：虽然常与上述框架并列提及 11，但它在技术上是一个库而非框架，并且更倾向于遵循单向数据流模型（如Flux/Redux），而非传统MVVM中常见的双向绑定。它同样实现了关注点分离，但数据流哲学有所不同。

  • Backbone.js：这是一个更早期的框架，更接近于MVC/MVP，但它展示了行业向结构化JavaScript应用发展的趋势 。


Web生态系统的发展揭示了一个有趣的趋势。虽然社区广泛接纳了MVVM的关注点分离思想，但对其核心的双向数据流机制却持有保留态度，认为它是复杂性和潜在错误的来源 。以React为代表的主流趋势更青睐可预测性更强的单向数据流。这种演变催生了所谓的“MV-Whatever”或基于组件的架构。它们保留了视图/逻辑分离的精髓，但用单向数据流和显式事件处理取代了双向绑定。这是对原始MVVM模式的一次重要架构分化。

。2 移动开发：声明式UI的复兴

  • 苹果的SwiftUI (iOS)：MVVM被认为是SwiftUI的天然搭档 。
    View是SwiftUI结构体，ViewModel是遵循ObservableObject协议的类，而绑定则由@StateObject和@ObservedObject等属性包装器处理 。然而，社区中存在激烈的争论，一些人认为这是将一个旧模式强行塞入新范式，另一些人则提倡使用类似Redux的单向数据流方法 。

  • 谷歌的Jetpack Compose (Android)：Compose是一个类似于SwiftUI的声明式UI工具包 。谷歌推荐的架构是一种分层方法，其中UI层（用Compose构建）观察来自
    ViewModel（Android架构组件的一部分）的状态 。数据流被明确设计为单向的：视图向视图模型发送事件，视图模型则暴露状态供视图观察 。这是对经典MVVM模式的清晰演进。


在这些现代声明式框架中，视图模型的角色正在发生微妙而重要的转变。在经典的MVVM（如WPF）中，视图模型通过INotifyPropertyChanged接口主动触发UI更新，是UI更新机制的积极参与者。而在SwiftUI和Compose中，框架本身负责观察状态变化并重新渲染UI（重组）。那么，视图模型的新角色是什么？它从一个


通知者转变为一个状态持有者和逻辑提供者。它封装了某个屏幕或组件的状态，以及响应事件以改变该状态的业务逻辑。这种转变解释了社区中的争论 14：那些只看到其旧通知者角色的人认为它多余；而那些看到其作为专用、可测试的状态管理和逻辑层新角色的人，则认为它比以往任何时候都更加重要，可以防止逻辑泄漏到庞大的视图结构中，并保持架构的整洁 。

。3 桌面开发：.NET生态系统

  • WPF (Windows Presentation Foundation)：MVVM模式的发源地和普及平台，是一个成熟的、仅限Windows的框架 。它拥有海量的文档和丰富的生态系统，但其发展已基本进入维护模式 。

  • Avalonia UI：一个现代、开源、跨平台的UI框架，深受WPF的启发 。它使用几乎相同的XAML和数据绑定语法，使得WPF开发者可以平滑过渡 。其核心优势是能够通过单一代码库在Windows、macOS和Linux上运行 。它正处于积极开发中，并获得了包括JetBrains在内的大公司的采用，发展势头强劲 。


平台/框架

视图实现

视图模型实现

绑定机制

数据流模型

WPF

XAML文件

实现INotifyPropertyChanged的C#类

XAML声明式绑定

双向绑定为主

Avalonia UI

XAML文件 (AXAML)

实现INotifyPropertyChanged的C#类 (常与ReactiveUI结合)

XAML声明式绑定 (语法与WPF几乎相同)

双向绑定为主

SwiftUI

SwiftUI View 结构体

ObservableObject 协议的Swift类

@StateObject, @ObservedObject等属性包装器

社区存在单向与双向流派之争

Jetpack Compose

@Composable Kotlin函数

Android架构组件ViewModel

State和Flow的观察

官方推荐单向数据流 (UDF)

Angular

HTML模板

TypeScript类

模板语法 [(ngModel)] 等

双向绑定为主

Vue.js

HTML模板

JavaScript/TypeScript对象

模板语法 v-model 等

双向绑定为主

React

JSX (JavaScript XML)

React组件自身逻辑或Hooks

JSX属性传递和状态管理 (e.g., useState)

严格单向数据流 (Flux/Redux)

第二部分：领域驱动设计——驯服软件核心的复杂性

本部分将焦点转向后端和业务逻辑，深入探讨领域驱动设计（Domain-Driven Design, DDD）作为一种构建健壮、可维护且与业务需求深度契合的系统的方法论。

第四节 DDD的哲学与宗旨

。1 定义DDD：超越模式集合

领域驱动设计是一种主要用于应对具有高度业务复杂性项目的软件设计方法论 。它不适用于简单的CRUD（增删改查）应用 。其核心前提是，软件的结构和语言应基于对业务领域的模型来构建 。DDD要求技术专家与领域专家（业务相关人员）之间进行密切协作 。

。2 统一语言：共享的基础

DDD的一个中心概念是创建统一语言（Ubiquitous Language）——一个由开发人员、领域专家和业务用户在所有沟通和代码中使用的、共享的、无歧义的词汇表 。这种语言源自业务领域，并被用来命名类、方法和模块，例如


LoanApplication（贷款申请）和AcceptOffer（接受报价）。其目标是消除业务概念和技术实现之间的歧义和翻译成本，从而减少误解 。

。3 领域模型：软件的核心

统一语言被用来构建领域模型，这是对业务领域的抽象 。这个模型不仅仅是数据模型，它封装了领域的数据（属性）和行为（业务规则和逻辑）。

第五节 战略设计：绘制业务版图

本节探讨DDD中用于指导整体架构和团队组织的高层次、“大局观”的概念。

。1 子域：分解问题空间

DDD认识到，大型系统过于复杂，无法用单一的统一模型来描述 。第一步是将整个领域分解为子域。这些子域通常分为：


  • 核心域（Core Domain）：业务中最关键、能提供竞争优势的部分。主要的设计精力应集中于此 。

  • 支撑子域（Supporting Subdomains）：业务运作所必需，但并非竞争优势所在。它们可能很复杂，但可以用比核心域较低的优先级在内部开发。

  • 通用子域（Generic Subdomains）：非业务特定的“现成”问题（如身份验证、邮件发送）。这些通常通过集成第三方库或服务来解决 。

。2 限界上下文：战略设计的关键

限界上下文（Bounded Context）是一个明确的边界，在边界内部，特定的领域模型被定义并且保持一致 。在限界上下文内部，统一语言具有精确、无歧义的含义。例如，“客户（Customer）”一词在“销售”上下文中可能意味着潜在客户评分，而在“支持”上下文中则可能意味着工单历史 。


限界上下文是模型应用的边界，是连接问题空间和解决方案空间的桥梁 。在微服务架构中，一个限界上下文通常是一个微服务的候选者 。


限界上下文的划分并非纯粹的技术活动，它深刻地反映了组织的社会技术结构。正如Martin Fowler所指出的，划分上下文边界的主导因素往往是“人类文化”，因为模型本身就是一种统一语言 。当语言（词汇和含义）在组织的不同部分发生变化时，就需要一个新的模型。组织中的不同团队或部门常常有自己的“方言”或专业词汇，例如26中提到的电力公司对“电表”一词的不同理解。因此，限界上下文的边界常常与团队或部门的边界对齐。“销售”上下文由销售团队拥有，“支持”上下文由支持团队拥有。这意味着战略设计不仅仅是划分代码的技术练习，更是一种将软件架构映射到组织结构和沟通模式的社会技术活动，这正是康威定律的现实应用。

。3 上下文映射：可视化模型间的关系

上下文映射图（Context Map）是一种图表或文档，用于可视化不同限界上下文之间的关系 。它定义了上下文如何集成和通信，使用的模式包括：


  • 合作关系（Partnership）：两个上下文/团队紧密合作。

  • 共享内核（Shared Kernel）：两个上下文共享一小部分通用模型。由于会产生耦合，需谨慎使用 。

  • 客户-供应商（Customer-Supplier）：“上游”上下文为“下游”上下文提供服务。

  • 防腐层（Anti-Corruption Layer, ACL）：下游上下文中的一个防御性层，负责将上游上下文的模型翻译成自己的模型，以保护自身模型不被外部概念“腐化” 。

第六节 战术设计：构建丰富领域模型的基石

本节将深入探讨在单个限界上下文内部，用于构建领域模型的具体、代码级别的模式。

。1 实体与值对象：模型的原子

  • 实体（Entity）：一个并非由其属性定义，而是由其随时间持续存在的唯一标识定义的对​​象 。例如：一个拥有唯一ID的
    Customer。

  • 值对象（Value Object）：一个由其属性定义、没有概念上标识的不可变对象 。例如：一个
    Money对象（包含金额和货币单位）或一个Address对象。两个具有相同街道、城市的Address对象被认为是相等的。

。2 聚合：一致性的守护者

  • 聚合（Aggregate）：一组被视为数据变更单元的关联对象（实体和值对象）的集群 。

  • 每个聚合都有一个聚合根（Aggregate Root），它本身是一个实体。聚合根是外部对象唯一被允许持有引用的聚合成员 。

  • 聚合的目的是在事务边界内强制执行业务规则和不变量（一致性规则）。对聚合内任何对象的所有更改都必须通过聚合根进行 。


聚合模式不仅仅是一种对象分组的方式，它在分布式系统中扮演着至关重要的角色。29和29将其定义为事务的“一致性边界”，并明确指出这与分布式应用中无法实现传统跨数据库事务的场景相关。34也讨论了在分布式系统中实现可靠原子提交和事件的困难。因此，聚合模式提供了一种在无法依赖数据库级别ACID事务时，在


应用层面维护数据一致性的解决方案。它定义了原子性的最小可能单元，这对于设计可靠的微服务至关重要。

。3 仓库、工厂与服务

  • 仓库（Repository）：一种封装了存储、检索和搜索行为的机制，它模拟了对象的集合 。它提供了对持久化层的抽象，使领域模型能够与持久化实现无关。视图模型或应用服务与仓库交互，而不是直接与数据库交互。

  • 工厂（Factory）：封装了创建复杂对象和聚合的逻辑，确保它们在创建时处于有效状态 。

  • 领域服务（Domain Service）：用于处理不适合放在实体或值对象中的领域逻辑，通常因为它涉及跨多个聚合的操作 。服务是无状态的。

。4 领域事件

领域事件是一种用于捕获和传达领域中已发生的、系统其他部分（或其他限界上下文）感兴趣的事情的机制 。例如：


OrderShipped（订单已发货）、CustomerBecamePreferred（客户成为首选客户）。事件对于实现限界上下文/微服务之间的松耦合和最终一致性至关重要 。

第七节 DDD的务实考量：应用场景与内在挑战

本节综合了DDD的“何时使用”与“为何不使用”，为决策提供务实的指导。

。1 应用场景：何时投资于DDD

  • DDD最适用于具有显著业务逻辑的大型复杂系统，而非简单的CRUD应用 。

  • 对于生命周期长、可维护性和适应性至关重要的项目，DDD是理想选择 。

  • 当能够接触到领域专家并与其合作构建统一语言和模型时，DDD的价值最高 。

  • 通过将复杂的遗留系统分解为不同领域，DDD可以成为重构这些系统的强大工具 。

。2 内在挑战与风险

  • 高昂的初始成本和学习曲线：在编写任何代码之前，DDD需要对领域探索和建模进行大量的前期投入。其概念可能难以掌握 。

  • 过度工程的风险：将DDD的复杂模式应用于简单问题，可能导致不必要的复杂性 。

  • 技术实现障碍：

    • 抽象开销：一个纯粹的、与框架无关的领域层需要许多抽象和映射，这可能感觉像是开销 。

    • 事务管理：围绕聚合管理事务，尤其是在分布式系统中，是一项不小的挑战 。

    • 可靠事件：确保领域事件与状态变更一起可靠、原子地发布，是一个重大的技术挑战 。


设计类型

焦点

关键概念/模式

主要产出

战略设计

宏观架构，系统分解，团队协作

子域、限界上下文、上下文映射图、统一语言

系统架构蓝图、团队边界、共享词汇表

战术设计

微观实现，单个限界上下文内的模型构建

实体、值对象、聚合、仓库、工厂、领域服务、领域事件

丰富的、可执行的领域模型代码

第三部分：综合与架构建议

最后一部分将连接前两个主题，探讨如何使用DDD来建模业务逻辑，并最终通过基于MVVM的UI呈现给用户这一常见而富有挑战性的任务。

第八节 统一方法：集成DDD与MVVM架构

。1 定义架构分层

一个结合了这两种模式的常见分层架构如下：


  • 表示层（UI）：使用MVVM实现，包含视图和视图模型 。

  • 应用层：协调用例。它不包含业务逻辑，而是指导领域层来完成来自UI的请求。视图模型与此层通信 。

  • 领域层：应用的核心，包含DDD领域模型（实体、聚合、领域服务）和业务逻辑 。

  • 基础设施层：包含持久化（仓库）、消息传递等的具体实现 。

。2 解决“模型激增”问题

一个常见的反模式是创建过多相似的模型类：一个视图专用模型、一个视图模型、一个领域对象和一个持久化实体 。


务实的解决方案：最有效的解决方案是直接将DDD领域对象用作MVVM模式中的“模型” 。视图模型将持有对领域对象（例如一个


Person对象）的引用。这消除了在表示层中需要一个单独的PersonModel以及它与领域Person对象之间的映射。这并不违反MVVM，因为该模式对“模型”的具体实现没有规定 。同样地，领域对象可以与持久化实体合并，使用映射配置（如实体框架的Fluent API）来处理持久化，从而消除


PersonEntity类并避免贫血领域模型 。

。3 视图模型交互与仓库的角色

视图模型不应包含业务逻辑。其角色是管理视图状态和委托操作。视图模型调用应用服务的方法 。应用服务随后使用


仓库来获取一个聚合，在聚合根上执行操作，并使用仓库保存更改。


仓库的放置：在客户端-服务器架构中，仓库模式可以存在于两个地方。客户端的视图模型可能与一个仓库接口交互，该接口抽象了对服务器的API调用。服务器端的应用服务则会与另一个仓库接口交互，该接口抽象了对数据库的访问 。这在应用的每一层都保持了清晰的分离。


要成功地将UI模式（MVVM）与业务逻辑模式（DDD）结合起来，关键在于它们之间需要一个中介层。如果视图模型直接与领域层对话，它可能会开始包含不属于UI的编排逻辑，例如为一个用户操作协调多个仓库或领域服务。DDD中的应用层概念完美地填补了这一空白 。它被设计为客户端请求的入口点，并负责协调领域模型。因此，最清晰、最具扩展性的集成模式是：


视图 <-> 视图模型 <-> 应用服务 <-> 领域模型。在这种模式下，视图模型的职责纯粹是表示状态和命令委托；应用服务的职责是用例编排；领域模型的职责是强制执行业务规则。这种由应用层协调的清晰职责分离，是成功整合这两种强大但不同架构方法的关键。

第九节 结论分析与专家建议

。1 核心发现总结

本次分析系统地阐述了MVVM和DDD的核心原则、优势与挑战。MVVM作为一种强大的UI分离模式，其具体实现正随着现代声明式框架的发展而演进。DDD则是一种用于管理长期业务复杂性的战略方法论，不应被轻率地应用于战术层面。

。2 架构决策框架

为帮助架构师做出决策，以下提供一组指导性问题：


  • 项目的规模和预期寿命是什么？（如果规模大且生命周期长，则倾向于DDD）。

  • 核心业务的复杂性如何？（如果复杂性高，DDD是强有力的候选者；如果低，更简单的CRUD架构可能就足够了）。

  • 目标平台和UI框架是什么？（这将决定要使用的MVVM的具体风格）。

  • 开发团队的专业知识和规模如何？（DDD需要团队的认同和更高的技能水平）。


最终建议是，对于复杂的现代应用，采用DDD构建核心业务逻辑、MVVM构建UI层的组合架构，提供了一个健壮、可扩展且可维护的解决方案，前提是各层之间通过应用层进行了正确的协调。

Works cited

。 数据绑定和MVVM - .NET MAUI | Microsoft Learn, accessed July 8, 2025, https://learn.microsoft.com/zh-cn/dotnet/maui/xaml/fundamentals/mvvm?view=net-maui-。0
。 Complete Guide to MVVM in SwiftUI [with Example] - Swift Anytime, accessed July 8, 2025, https://www.swiftanytime.com/blog/mvvm-in-swiftui
。 Android Compose Tutorial | Jetpack Compose | Android Developers, accessed July 8, 2025, https://developer.android.com/develop/ui/compose/tutorial
。 What Is MVVM (Model-View-ViewModel)? | Built In, accessed July 8, 2025, https://builtin.com/software-engineering-perspectives/mvvm-architecture
。 Architectural Pattern - MVVM (Model-View-ViewModel) - DEV ..., accessed July 8, 2025, https://dev.to/binoy123/architectural-pattern-mvvm-model-view-viewmodel-2jaa
。 Understanding MVVM: Model-View-ViewModel Architecture Explained - Ramotion, accessed July 8, 2025, https://www.ramotion.com/blog/what-is-mvvm/
。 mvvm mvc区别-阿里云, accessed July 8, 2025, https://www.aliyun.com/sswb/。html
。 MVC、MVP、MVVM区别| springleo's blog, accessed July 8, 2025, https://lq782655835.github.io/blogs/js/think-different-MVC-MVP-MVVM.html
。 Advantages of MVVM - Tutorials Point, accessed July 8, 2025, https://www.tutorialspoint.com/mvvm/mvvm_advantages.htm
。 Are we going backwards using a JavaScript MVC (MVVM) framework like Backbone.js, Angular, etc.? [closed] - Stack Overflow, accessed July 8, 2025, https://stackoverflow.com/questions/14821599/are-we-going-backwards-using-a-javascript-mvc-mvvm-framework-like-backbone-js
。 27 Best JavaScript Frameworks For 2025 | LambdaTest, accessed July 8, 2025, https://www.lambdatest.com/blog/best-javascript-frameworks/
。 The Most Popular JavaScript Frameworks in 2025 - Mobilunity, accessed July 8, 2025, https://mobilunity.com/blog/top-20-javascript-frameworks-chosen-by-remote-developers-in-2024/
。 MVVM in SwiftUI for a Better Architecture [with Example] - Matteo Manferdini, accessed July 8, 2025, https://matteomanferdini.com/swiftui-mvvm/
。 SwiftUI best architecture - Reddit, accessed July 8, 2025, https://www.reddit.com/r/SwiftUI/comments/199hkf8/swiftui_best_architecture/
。 ‍ Android Compose: Create a simple MVVM project with basic four layers | by Michael M.H | Medium, accessed July 8, 2025, https://medium.com/@anteprocess/android-compose-create-a-simple-mvvm-project-with-basic-four-layers-776b586d00af
。 MVVM with Jetpack Compose: Structuring Your App for Clean Architecture - Medium, accessed July 8, 2025, https://medium.com/@sks727633/mvvm-with-jetpack-compose-structuring-your-app-for-clean-architecture-42f4bad4c99e
。 Why Avalonia UI is better then WPF – Coding is Amazing, accessed July 8, 2025, https://codingisamazing.com/why-avalonia-ui-is-better-then-wpf/
。 From WPF to Avalonia: A Guide for .NET Developers Exploring ..., accessed July 8, 2025, https://avaloniaui.net/blog/from-wpf-to-avalonia-a-guide-for-net-developers-exploring-cross-platform-ui-frameworks
。 Avalonia UI vs WPF : r/dotnet - Reddit, accessed July 8, 2025, https://www.reddit.com/r/dotnet/comments/ru0jus/avalonia_ui_vs_wpf/
。 DDD在大众点评交易系统演进中的应用- 美团技术团队, accessed July 8, 2025, https://tech.meituan.com/2024/05/09/ddd-practice-trading-system.html
。 Domain Driven Design: Should you apply it? - DEV Community, accessed July 8, 2025, https://dev.to/boma/domain-driven-design-should-you-apply-it-570o
。 领域驱动设计- 维基百科，自由的百科全书 - Wikipedia, accessed July 8, 2025, https://zh.m.wikipedia.org/zh-cn/%E9%A0%98%E5%9F%9F%E9%A9%85%E5%8B%95%E8%A8%AD%E8%A8%88
。 How Domain-Driven Design helps me tackle everyday challenges in software design, accessed July 8, 2025, https://blog.dy.engineering/how-domain-driven-design-helps-me-tackle-everyday-challenges-in-software-design-2347b02b85d6
。 What is Domain-Driven Design? Benefits, Challenges & Implementation - Port IO, accessed July 8, 2025, https://www.port.io/glossary/domain-driven-design
。 領域驅動設計- 維基百科，自由的百科全書, accessed July 8, 2025, https://zh.wikipedia.org/zh-tw/%E9%A0%98%E5%9F%9F%E9%A9%85%E5%8B%95%E8%A8%AD%E8%A8%88
。 Bounded Context - Martin Fowler, accessed July 8, 2025, https://martinfowler.com/bliki/BoundedContext.html
。 Benefits of adopting DDD in your company | by Norman Coloma ..., accessed July 8, 2025, https://medium.com/@normancolomagarca/benefits-of-adopting-ddd-in-your-company-899863edbf37
。 Modeling Shared Entities Across Bounded Contexts in Domain-Driven Design, accessed July 8, 2025, https://dev.to/aws-builders/modeling-shared-entities-across-bounded-contexts-in-domain-driven-design-5hih
。 使用战术性DDD 来设计微服务- Azure Architecture Center | Microsoft ..., accessed July 8, 2025, https://learn.microsoft.com/zh-cn/azure/architecture/microservices/model/tactical-ddd
。 Bounded Context | DevIQ, accessed July 8, 2025, https://deviq.com/domain-driven-design/bounded-context/
。 Blog: From Good to Excellent in DDD: Understanding Bounded Contexts in Domain-Driven Design - 8/10 - Kranio, accessed July 8, 2025, https://www.kranio.io/en/blog/de-bueno-a-excelente-en-ddd-comprender-bounded-contexts-en-domain-driven-design---8-10
。 领域驱动设计在互联网业务开发中的实践 - 美团技术团队, accessed July 8, 2025, https://tech.meituan.com/2017/12/22/ddd-in-practice.html
。 Challenges With Implementing DDD - DZone, accessed July 8, 2025, https://dzone.com/articles/challenges-implementing-ddd
。 Challenges implementing DDD. I have finished reading the DDD books… | by Dmytro Stepanyshchenko | CodeX | Medium, accessed July 8, 2025, https://medium.com/codex/challenges-implementing-ddd-4113d602caf6
。 Using MVVM and DDD in WPF application without having too many classes - Stack Overflow, accessed July 8, 2025, https://stackoverflow.com/questions/38431091/using-mvvm-and-ddd-in-wpf-application-without-having-too-many-classes
。 Comparison of MVC with MVP/MVVM/DDD Architectures Implemented in Different Languages | by 刀法如飞 | Medium, accessed July 8, 2025, https://medium.com/@microwind/comparison-of-mvc-with-mvp-mvvm-ddd-architectures-implemented-in-different-languages-5369a1383f49
。 WPF + MVVM + DDD - how to combine them together? : r/dotnet - Reddit, accessed July 8, 2025, https://www.reddit.com/r/dotnet/comments/4kczyq/wpf_mvvm_ddd_how_to_combine_them_together/
。 .net - MVVM, DDD, and WPF Layered Application Project Structure ..., accessed July 8, 2025, https://softwareengineering.stackexchange.com/questions/159283/mvvm-ddd-and-wpf-layered-application-project-structure-guidance


评论