浅谈DDD(domain-driven design-领域驱动设计)

原文地址: https://juejin.im/post/6845166891670093838

划了半年,现在开始接客!

❝本篇文章存在大量干货,建议调整姿势反复观看,所有技术栈通用,本文以vue项目为例❞

「好代码一定是设计出来的!而不是用多么牛逼的技术栈」

DDD

注意这不是大笑表情包,DDD(domain-driven design-领域驱动设计),大部分前端接到需求的时候都在思考这个原型我要怎么实现某块功能细节(用哪个UI库、该怎么写),即使不了解业务也一样可以开发,通常也能完成工作,这种情况称为 ——「面向功能编程(没有思考的前端资源)」

然而,随着业务的深入、需求不断地迭代和变更,我们(前端)仿佛在负重前行,为什么?

  • 业务不熟悉,不知道为什么要改需求,也不知道修改需求影响了原来哪块代码
  • 历史包袱多,投入相较后端越来越重

领域怎么划分?

[data:image/svg+xml;utf8,<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1030" height="284"></svg>](data:image/svg+xml;utf8,<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1030" height="284"></svg>)

差不多就是这样抽象(就硬划),建议和后端同学进行 「深入♂♂探讨」(抽象能力个人认为需要学习思考+后天培养,也不能指望文章)

❝我认为应该在了解产品(或行业领域)的前提下进行软件开发,先根据项目抽象出业务边界模块,建立领域再动手开发。❞

沙箱

[data:image/svg+xml;utf8,<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="570" height="374"></svg>](data:image/svg+xml;utf8,<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="570" height="374"></svg>)

❝哎呀,你这个代码怎么参数乱七八糟,方法全依赖在一起我都不敢改啊,怎么一个js有9000行❞

我们先来康康什么是沙箱(sandbox),安全独立的,隔离外界的,互不影响的环境结构。

看起来好像没什么,我们再看看设计模式应该准许你的准则,

  • 单一原责
  • 迪米特(最少知识)原则
  • 开放封闭原则
  • 依赖倒置
  • 接口隔离
  • 里式替换

是不是觉得DDD和设计原则、沙箱环境都有相同想强调的地方?

好像又绕回来了,唠了半天,尽和我搞文绉绉的文字游戏,是你需要30万还是想爬山

上一篇:Vue2.x响应式原理


下一篇:论文阅读笔记StyleCLIP: Text-Driven Manipulation of StyleGAN Imagery