DDD（1）——领域驱动设计架构的四个层次，及依赖关系

在领域驱动设计（Domain-Driven Design，简称DDD）中，系统通常被划分为以下四个核心层次： 用户界面层 (UI层)：这是用户与系统交互的地方，也就是我们通常说的前端部分。 应用层 (Application层)：这一层为用户界面层提供所需的应用功能。它并不直接包含业务逻辑，而是负责协调和指导领域层和基础设施层如何工作以完成特定的用户故事或用例。 领域层 (Domain层)：这里包含

实战首选缓存策略，保证 Redis 和 MySQL 的一致性

（这里说的“首选”，是一般而言。根据具体情况，可能有更合适的方案。） 1 关于缓存的共识 想使用缓存，首先要达成以下共识： 缓存必须要有过期时间； 保证数据库跟缓存的最终一致性即可，不必追求强一致性。 尤其是第二点，这是一个 TradeOff。如果非得要求强一致性，就不要用缓存。 本文讨论的策略，只是保证最终一致性。 2 实战首选：旁路缓存策略（Cache-Aside） 进入正题。我在实际工作中，

浅谈模块化设计

1 模块与模块化设计 1.1 什么是模块？ 广义来说，模块就是“一个软件块”，下至函数、类，上至服务、应用，都可称之为模块。但这样的说法未免过于笼统，本文讨论的模块是狭义的，定义如下： 软件模块是可部署的、可管理的、原生可重用的、可组合的、无状态的软件单元，它为用户提供了简洁的接口。 可部署：模块是一个独立部署单元（因此区别于类和包）。 可管理：模块是一个可管理的单元。模块可以单独安装、卸载以及更

4+1 视图定义

网上的资料各有不同。这里给出一版我的定义。 视图 内容 作用 用例视图 用例图。从用户角度出发，梳理技战法平台的所有使用场景（用例） 圈定功能范围 逻辑视图 对系统的静态描述： 定义系统的逻辑元素（模块、组件），并分配职责 描述逻辑元素间的关系：接口、组织架构等 描述系统的组成部分 对系统进行逻辑分解，尽量做到高内聚低耦合，便于分锅 过程视图 对系统的动态描述： 组件之间的数据流向（即我们常用的数