这是一个创建于 1171 天前的主题，其中的信息可能已经有所发展或是发生改变。
我是 ddd 这方面的新手，入门快两年了，还是不明白里面的缘由。
所以在 v 站上面，寻找这方面知友，相互学习一下，有兴趣的留个 v 。
人多的话，可以创个群
所以在 v 站上面，寻找这方面知友，相互学习一下，有兴趣的留个 v 。
人多的话，可以创个群
第 1 条附言 2022-07-27 11:43:28 +08:00
包含战术设计，战略设计，不仅仅是代码实战，还有 uml ，架构设计啥的
 | 1 Masterlxj 2022-07-27 10:58:33 +08:00 领域驱动设计？ |
 | 3 woostundy 2022-07-27 11:40:32 +08:00 d29vc3R1bmR5X3Njcm0K |
 | 4 coderxy 2022-07-27 11:40:35 +08:00  3 1000 个开发就有 1000 种 DDD |
 | 5 q474818917 2022-07-27 11:49:27 +08:00 都 2202 年了，还有人在琢磨这玩意。。。 |
 | 6 dx3759 2022-07-27 11:56:47 +08:00 @q474818917 这句话怎么解？ 49 年入国？ |
 | 7 guaike 2022-07-27 12:00:45 +08:00 不要太执着于 DDD ，这个模式都炒了 n 年了，现在还是一样没有什么标准，也没有看到真正强有说服力的工程实践 |
 | 8 ysjiang4869 2022-07-27 12:28:47 +08:00 via Android 目前看了一点，最新的一点感受是，在 ddd 的指导下，一些日渐庞大的项目，后期拆分微服务会比较轻松。目前我们很多项目都大到本地编译超级慢，但是柔和依赖特别多，拆不动了 |
 | 9 jamel OP @ysjiang4869 其实最难的是 uml ，uml 会了 ddd 就会了 |
 | 10 frank1256 2022-07-27 13:55:57 +08:00 今年上头非要整 ddd ，找了一个项目硬着头皮 ddd 去写。很烦，也很觉得没什么意义。也很难写的下去，各种概念。 但是中途我发现自己代码有问题，进行少量重构的时候，能感觉到如果不按 ddd 的思想去写，代码改动量很大。“领域专家”这个东西很重要。 |
 | 12 nzbin 2022-07-27 14:31:03 +08:00 |
 | 13 lanlanye 2022-07-27 15:27:48 +08:00 RnJvbUFyY2FkaWE= |
 | 14 frankly123 2022-07-27 15:28:00 +08:00 1000 个开发就有 1000 种 DDD |
 | 15 hangbale 2022-07-27 16:59:17 +08:00 前两年吹上天的微服务让 DDD 又火了把，其实不过是这十年互联网发展太快，留下的屎山代码太多，不得已开始搞重构，最终有的成功了，有的一地鸡毛。 DDD 是 04 年提出的东西，只是个抽象的思维方式，如今大多数项目都远比那个时代的复杂，只要能套，或多或少都用到了 DDD 。 |
 | 16 NoNewWorld 2022-07-27 17:39:09 +08:00 最近 DDD 的入门资料挺多的，各种小册、书籍、视频撒的。不过和上面大佬们说的一样，每个人眼中的 DDD 都不同，目前我觉得可以看看 COLA 那一套吧。 |
 | 17 bz5314520 2022-07-27 17:44:10 +08:00 最重要的是战略部分 |
 | 18 dr1q65MfKFKHnJr6 2022-07-27 18:15:15 +08:00 1 @jamel UML 只是工具， 大学有个专门的课程， 不过只要求能看懂 UML 图，“行业专家” 基本不会是程序员出身， 开发要做的是“翻译、领会、吃透”行业专家的知识、经验， 最后把自己弄成所谓的领域专家。 没有行业专家，基本很难成“领域专家”. 个人理解 |
 | 19 sutra 2022-07-27 19:25:41 +08:00 也不留个 t 。 |
 | 20 unregister 2022-07-27 23:26:49 +08:00 公司新项目开始搞 DDD 了，但是写的实体类还基本都是贫血模型。 |
 | 21 7911364440 2022-07-28 09:19:27 +08:00 极客时间上有一门讲 DDD 的课，可以看一下 |
 | 22 dk7952638 2022-07-28 09:37:58 +08:00 曾经疯狂沉迷过一段时间 DDD ，实践几次后发现这玩意根本就没什么最佳实践，就像是 雄安新区 一带一路 顶层设计 千年大计 宏大叙事的本质是一样的 |
 | 23 nothingistrue 2022-07-28 09:48:41 +08:00 既然 DDD 了，就别搞微信这么搓的交流工具了。IM 工具不适合技术性交流，要找社区交流工具。 个人一点拙见，DDD 最难的不是技术部分（战略设计也是技术部分），而是如何让需求跟开发形成通用语言。要是还用界面原型、效果图、甚至领导的想法来定义需求，那是用不成 DDD 的。最低的极限也得是拿数据库设计得概要模型或者逻辑模型当主要需求（界面原型只做辅助）。 |
 | 24 BrightLiao 2022-07-28 15:46:37 +08:00 DDD 的核心指导思想是：深入研究领域，消化知识，充分沟通，然后用软件模型对问题进行深刻的抽象，最终得到一个富含知识的领域模型。DDD 的实现不在于用何种方法，而是看最后是否得到了良好的深刻的领域模型。 个人有一些之前的思考和实践经验，给大家分享一下： 代码中的领域： https://brightliao.com/2019/08/08/domain-concept-in-your-code/ 用 DDD 思想来编写 Pipeline: https://brightliao.com/2020/01/05/DDD-in-pipeline-code/ |
 | 25 ming159 2022-07-28 16:42:44 +08:00 我来说一下 1/1000 DDD 1. 问题领域识别: 明确你面对问题所在领域. 例如 你要完成一个用户登录功能. 那么 往大了说,这属于 "信息安全领域" 2. 领域建模: 将这个领域中的处理模型搞清楚,并映射为对应的计算机语言设计,例如面向对象设计,将这个领域中的对象设计出来. 所以,起始最核心的是 "领域专家 " 这个角色,他有充分的专业知识和经验 能够给最初设计给出完整的领域知识的指导. 而程序员通常是计算机的"领域专家",并不是信息安全领域的,也不是 财务方面的,也不是仓库,物流,运营方面的. 如果领导让程序员去 DDD 本身就不是靠谱的事. 再退一步,其实实际工作中,"领域专家" 90% 情况下不存在.大家几乎都是自己岗位的熟练工而已....如果不信可以找公司会计问问,如果要开发一个 财务系统,希望他给你讲讲财务领域的知识,同时让他给设计建议,保证你最后实现了,也就你们公司能用. 根本达不到 财务领域 通用的程度. |
 | 26 10Buns 2022-07-29 09:55:00 +08:00 @BrightLiao 请问主题是什么名字？ |
| 27 BrightLiao 2022-07-29 11:56:50 +08:00 @10Buns 什么主题？ |
 | 28 zhangwugui 2022-07-29 16:02:14 +08:00 留个 V：love_jacks_2005 ，一块学习下；或者拉个群 |
Select Language