对DDD四层架构落地的简单理解

已于 2023-11-12 18:56:05 修改
阅读量328 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： DDD 架构 文章标签： 架构
于 2023-11-12 18:54:18 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/mikewuhao/article/details/134364024
本文介绍了如何实现一个可落地的代码工程结构，包括接入层的HTTP接口和RPC接口、定时任务以及通用类，应用层的轻量级转发与协调，领域层的核心业务逻辑，以及基础设施层对数据库、缓存和云服务的操作。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

可落地的代码工程结构

demo-interface —接入层：提供外部/前端http接口，提供三方rpc接口，定时任务job，common类（异常类，枚举类）
demo-application —应用层，不包含业务逻辑，很薄一层，主要为下层转发，协调，装配等工作。如启动类，配置类，认证授权.
demo-domain —领域层，涉及核心业务，实体，聚合，值对象，领域事件, 具体业务代码
demo-infrastructure —基础设施层：操作DB，Redis, ES, OSS，配置类等。

后续会持续更新…

DDD系列 - 第0讲 DDD中常提到的应用架构总结（六边形、洋葱、整洁、清晰）
罗小爬的技术宝书
07-09 8077
最近在学习DDD应用架构设计时，接触到了不同的应用架构设计概念，如六边形架构、洋葱架构、整洁架构、清晰架构...，起初是一头雾水，在不断学习过程中也算对此有了些理解，故在本文中对这些架构进行了简单的介绍和总结。............
DDD进阶_DDD分层架构、整洁架构、六边形架构
日积月累，水滴石穿
06-25 5437
DDD从入门到精通，系列文章传送地址，请点击本链接。 本文主要讲解微服务不同架构下的特点，如果还不了解DDD分层架构的，请先学下DDD的分层架构整洁架构又名“洋葱架构”。为什么叫它洋葱架构？看看下面这张图你就明白了。整洁架构的层就像洋葱片一样，它体现了分层的设计思想。在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心
DDD微服务架构设计第七课 基于 DDD 的代码设计演示
fegus的博客
05-16 1199
16 基于 DDD 的代码设计演示（含 DDD 的技术中台设计） 我这些年的从业经历，起初是作为项目经理带团队做软件研发，后来转型成为架构师，站在更高的层面去思考软件研发的那些事儿。我认为，一个成熟的软件研发团队： 不仅在于团队成员研发水平的提高； 更在于将不断积累的通用的设计方法与技术框架，沉淀到底层的技术中台中。 只要有了这样的技术中台作为支撑，才能让研发团队具备更强的能力，用更快的速度，研发出更多的产业，以快速适应激烈竞争而快速变化的市场。 譬如，团队某次接到了一个数据推送的需求，在完成
DDD领域驱动模型看起来很抽象，自己搭建的Demo希望能帮助大家
weixin_47616767的博客
09-11 646
DDD领域驱动模型设计
DDD部分应用之项目重构demo
tiway的博客
04-14 2327
最近一直在学习DDD相关内容，通过近几个月的学习也确实感觉到我们现有项目的一些缺陷。 项目介绍 目前项目项目架构 项目框架：YII2 1.在controller 层得到对应版本号映射对应的service,每个版本对应一个service public function __construct($id, $module, $config = []) { parent::__construct($id, $module, $config); //获取对应service版本
DDD架构图
ejinxian的专栏
06-14 3572
架构又是最稳定的，不会因为各种具体技术的依赖，如各种UI框架、ORM框架、IoC框架的更新换代而受到影响。上文的总结没有任何Demo是因为架构更偏向于设计层面，有从设计视图创建解决方案经验的人，一看就知道我在说什么。本文将展示从架构设计视图到.NET多项目解决方案的过程。主要包含以下内容：（1）演示DDD分层架构到.NET多项目解决方案的映射。（2）演示DDD分层依赖到.NET项目引用的映射。（3）
DDD的应用框架实践分享
yxkong的专栏
07-14 765
分享一个DDD的应用框架，写了一个简单的demo。已经在在生产实践。git地址： https://github.com/yxkong/ddd-framework框架结构如下：项目结构如下：示例流程图：简单说明：只启动一个应用在adapter层启动；接口请求到adapter层，调用DistributeController；controller层做上下文转化以及调用application层；application层进行模型依赖构建，以及领域执行前后的特殊处理；domain层进行了业务逻辑实现（和技术框架无关），
DDD分层架构参考代码目录结构
04-19
微服务的一级目录结构通常按照DDD的四层模型划分，如interfaces、application、domain和infrastructure。 在接口层，interfaces目录下，包括了 assembler、dto和façade三个子目录。Assembler负责DTO（Data ...
DDD领域驱动设计实战落地解惑-SACC2021年中国系统架构师大会.pdf
04-29
对于传统开发者的三层分包（表示层、业务逻辑层、数据访问层）思维模式，四层架构虽有所差异，但相对容易理解和上手。 领域事件是DDD中的一个核心概念，它对应业务中的重要事件或状态变化。DDD事件发布订阅机制允许...
DDD领域应用理论实践分析回顾
热门推荐
张彦峰的博客
12-01 7万+
探讨领域驱动设计（DDD）在现代软件开发中的重要性，以复杂的B端营销系统为例看实际应用。
DDD领域驱动设计内容分享(十)：去哪儿的DDD架构实操之路
之乎者也·的博客
12-28 1501
上列四张图简单展示了去哪儿网本次重构的主题，也是酒店基础信息部所负责的业务。列表页：用户打开 APP，输入目的地和入住时间，点击搜索，便会转到列表页，展现搜索地点的所有酒店列表信息。详情页：点击希望入住的酒店，即可进入详情页。酒店Info：点击酒店名字，则可进入酒店Info页。进订页：用户决定预定酒店房间后，就跳转到进订页。组织资源是否集中在了核心业务领域；是否能用统一语言沟通描述业务，体现在需求评审、站会等有关会议的效率上；领域知识是否得到沉淀，是否有人能承担“领域专家”；
定时器案例
qq_64421953的博客
03-31 818
定时器：就好比一个闹钟，在一定时间之后，被唤醒并执行某个之前设定好的任务 整体操作： 1）描述一个任务：Runnable + time 2）使用优先队列来组织若干个任务，PriorityBlockingQueue 3）实现schedule方法来注册任务到队列中 4）创建一个扫描线程，这个扫描线程不停的获取到队首元素，并且判断时间是否到达 注意问题：让MyTask类能够支持比较，以及注意解决“忙等”问题 说到计时器就需要Java.util.Timer包 这个包的核心方法就一个，schedule
DDD领域设计架构落地
a5498665的博客
03-13 1297
DDD领域驱动设计架构落地实现
DDD的代码结构
ronshi的博客
05-22 5846
DDD的代码结构
设计模型之DDD开发模式
JennyXi2001的博客
03-17 5481
服务是一种用于封装领域逻辑的对象，它不属于任何特定的实体，而是用于处理跨实体的业务逻辑。它包含了应用程序的控制器（Controller），负责接收用户的请求、调用相应的服务（service）处理业务逻辑，并将处理结果返回给用户。在基础层中，“rpc” 可能包含与远程服务调用相关的代码或模块，用于实现不同系统之间的通信和集成。实体通常封装了领域中的业务逻辑，负责处理自身状态的变化和行为的操作。在基础层中，“mq” 可能包含与消息队列的集成和使用相关的代码或模块，用于实现应用程序之间的异步消息通信和事件驱动。
COLA 4.0 - DDD项目实践
uuqaz的博客
07-19 4031
此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。CQRS架构模式，在DDD中是一种很常见的模式，它的用途在于将Command与Query功能进行分离，让一些复杂的查询摆脱领域模型的限制，以更为简单的DTO形式展现查询结果。4）领域层（DomainLayer）主要是封装了核心业务逻辑，并通过领域服务（DomainService）和领域对象（DomainEntity）的方法对App层提供业务实体和业务逻辑计算。...
DDD 四层微服务架构，开箱即用！
码猿技术专栏
01-18 452
大家好，我是不才陈某~大家看到的这张架构图并不是空穴来潮，它是通过不断演变出来的，我们要从DDD四层架构、微服务架构两个维度去融合理解。这里的DDD四层架构适用于单个服务的工程架构（如图中的左下部分），就是单体应用的DDD四层架构的包划分方式。而微服务架构，则是从整体去看，整合多个单体应用，它们之间通过应用SDK工程进行RPC通讯。微服务架构下的应用SDK这个工程比较好理解，类似于我们传统的理解的...
DDD分架构模型介绍
学亮编程手记
01-13 2758
同样的道理，当我们使用HTTP对服务的进行请求的时候，如果遵循了REST风格的架构风格，便可以获得由于使用了REST风格的HTTP所带来的好处。（Snapshot），但是对于请求量级比较大的情况，频繁的去创建快照也是非常消耗资源的，所以，我们可以自定义一个阈值（例如：事件数超过50个），当超过这个阈值的时候，我们在创建这个聚合状态的快照，从而获得最优的聚合创建与获取效果。，用户读取数据的时候，先查询缓存，如果不存在，再去查询模型的数据库中获取。，即：在展示数据后面，增加当前所展示的数据的创建时间。
【基于电商履约场景的 DDD 实战】阿里巴巴开源的 Cola 架构设计
qq_45260619的博客
01-30 3188
欢迎关注公众号（通过文章导读关注：【11来了】），及时收到 AI 前沿项目工具及新技术的推送！ 在我后台回复 「资料」 可领取编程高频电子书！ 在我后台回复「面试」可领取硬核面试笔记！ 文章导读地址：点击查看文章导读！ 感谢你的关注！
管理层和架构师哪个发展方向比较好
最新发布
02-28
<think>嗯，用户问的是管理层和架构师哪个发展方向比较好。首先，我需要理解这两个角色的核心差异。管理层通常指的是进入公司的高层，负责团队管理、项目协调、资源分配等，而架构师则是技术专家路线，专注于系统设计、技术选型、解决复杂技术问题等。 接下来，用户可能是一位在IT行业工作了一段时间的技术人员，面临职业发展的选择。他可能对当前的技术路线感到满意，但也在考虑是否转向管理岗位，或者继续深入技术成为架构师。需要明确的是，用户的需求不仅仅是了解两者的区别，而是希望得到职业规划的建议，帮助他做出最适合自己的选择。 要回答这个问题，我需要比较两者的职责、所需技能、发展前景以及适合的人群。同时，要考虑到用户的个人兴趣、性格特点以及长期职业目标。比如，如果他喜欢与人打交道，擅长协调和领导团队，可能更适合管理层；如果他更热爱技术，喜欢解决复杂问题，那么架构师可能更适合。 此外，还需要分析当前市场趋势，比如技术专家的需求是否在增长，管理岗位的竞争情况如何。现在很多公司越来越重视技术架构，尤其是在云计算、大数据等领域，架构师的作用愈发重要。而管理层则需要更强的软技能，如沟通、决策能力等。 可能还需要提到，两者并非完全对立，有些架构师会逐渐转向技术管理，比如CTO这样的角色，既需要技术深度，也需要管理能力。因此，用户也可以考虑分阶段发展，先深入技术成为架构师，再逐步转向管理，这样既有技术背景，又有管理经验，更具竞争力。 另外，用户可能关心的点包括薪资水平、工作压力、职业寿命等。架构师通常薪资较高，但需要不断学习新技术；管理层可能压力更大，但职业发展路径更广。需要根据用户的个人价值观和生活方式来权衡。 还要注意避免主观臆断，提供客观的信息，比如引用行业数据或案例，说明两者的优缺点，帮助用户全面了解。同时，应该鼓励用户自我评估，比如通过性格测试或职业咨询，找到最适合自己的方向。 最后，总结时应该强调没有绝对的好坏，关键在于个人适配度。建议用户结合自身兴趣、能力和长期目标，选择能持续成长并带来成就感的路径。</think>在选择**管理层**与**架构师**发展方向时，需结合**个人特质**与**行业趋势**综合判断。以下从6个维度进行深度对比分析： --- ### **一、核心价值对比** | 维度 | 管理层 | 架构师 | |--------------|--------------------------------|---------------------------------| | **价值焦点** | 资源整合与目标达成 | 技术决策与系统可靠性 | | **决策场景** | 跨部门协调（如产品-技术博弈） | 技术选型（如Kafka vs Pulsar） | | **风险类型** | 项目延期追责 | 架构缺陷导致生产事故 | **典型案例**： - 某电商大促期间，技术总监需平衡**研发投入**与**ROI**（将50%资源投入流量预估模型优化） - 首席架构师主导**服务网格化改造**，将单体应用拆分误差率控制在0.5%以下 --- ### **二、能力模型差异** #### **管理层必备能力** 1. **政治敏感度**：识别公司权力结构（如CTO与CFO的博弈策略） 2. **成本控制**：精确计算人力成本（如外包团队使用比例对OKR的影响） 3. **向上管理**：用**数据叙事法**包装技术成果（将QPS提升转化为GMV增长预期） #### **架构师核心能力** 1. **技术预判**：提前2年布局技术栈（如2023年评估Serverless在核心交易系统的可行性） 2. **故障推演**：设计混沌工程场景（模拟Region级机房故障时的服务降级路径） 3. **抽象建模**：将业务需求转化为领域模型（DDD在金融清结算系统的落地实践） --- ### **三、发展路径对比** #### **管理层晋升通道** ```mermaid graph LR A[技术骨干] --> B[项目经理] B --> C[部门经理] C --> D[技术总监] D --> E[CTO/COO] ``` **关键转折点**： - 从**技术贡献者**到**团队放大器**的思维转变（学会通过他人拿结果） - 建立**跨部门同盟**（如与HRBP合作设计技术序列晋升规则） #### **架构师成长路径** ```mermaid graph LR A[高级开发] --> B[系统架构师] B --> C[领域架构师] C --> D[首席架构师] D --> E[技术院士] ``` **能力跃迁**： - L3到L4需掌握**复杂系统建模**（如基于Event Sourcing的分布式事务方案） - L5以上要求**行业影响力**（在ArchSummit等会议输出方法论） --- ### **四、薪酬与风险** | 职级 | 管理层薪资区间（年薪） | 架构师薪资区间（年薪） | 职业风险 | |------------|------------------------|------------------------|---------------------------| | 初级(P6) | 50-80W | 60-90W | 管理层：团队流失风险 | | 中级(P8) | 100-150W | 120-180W | 架构师：技术决策失误风险 | | 高级(P10) | 200W+股权 | 250W+期权 | 管理层：战略方向错误 | **注**：头部互联网企业数据，含股票期权 --- ### **五、35岁危机应对** #### **管理层生存策略** - 构建**跨行业人脉网**（加入长江商学院等圈子） - 转型**业务负责人**（如从技术VP转任智慧城市事业部总经理） #### **架构师破局方法** - 深耕**垂直领域**（成为AI基础设施领域TOP3专家） - 输出**行业标准**（参与编写《金融级云原生架构白皮书》） --- ### **六、决策树模型** 用以下问题评估适配度： 1. 看到技术文档更新是否兴奋？ - 是 → 偏向架构师 - 否 → 考虑管理岗 2. 处理部门冲突时更倾向于： - 技术方案折中 → 架构师 - 资源置换谈判 → 管理层 3. 职业满足感来自： - 系统扛住双11流量 → 架构师 - 团队超额完成OKR → 管理层 --- **建议选择策略**： - **技术狂热者**：优先走架构师路线，35岁后可选CTO技术管理双路径 - **资源整合者**：早期切入管理岗，但需保持技术敏感度（定期参加Architect峰会） - **折中方案**：先成为**技术经理**（70%技术+30%管理），5年后根据市场变化再分化 当前行业数据显示：**顶尖架构师的薪酬天花板比同级别管理层高20%-30%**，但管理岗的跨界发展机会更多（如转投融资领域）。建议每18个月重新评估一次发展方向。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值