BrightLiao 最近的时间轴更新
BrightLiao's repos on GitHub
11 人关注
ai-workshop-notes
8 人关注
dl-workshop
JavaScript · 5 人关注
bicycle
A lightweight framework based on express. Targeting to absolutely seperate server and client development.
Jupyter Notebook · 5 人关注
dl-workshop-rnn-lstm
Deep Learning workshop: RNN & LSTM
Java · 5 人关注
DroidIncUpdate
JavaScript · 4 人关注
bicycle-admin
An app of bicycle framework. Targeting to easier create admin website.
Jupyter Notebook · 1 人关注
ai-workshop
PHP · 1 人关注
dokuwiki
The DokuWiki Open Source Wiki Engine
TypeScript · 0 人关注
activiti-modeling-app
Activiti Modeling Application
0 人关注
Awesome-Scene-Text-Recognition
A curated list of resources dedicated to scene text localization and recognition
Shell · 0 人关注
bigdata_conf
Java · 0 人关注
bigdata_demo
JavaScript · 0 人关注
bright-lgm.github.io
Personal blog
Java · 0 人关注
camel
Apache Camel
JavaScript · 0 人关注
chinese-independent-blogs
中文独立博客列表
Python · 0 人关注
chinese-ocr
运用tensorflow实现自然场景文字检测,keras/pytorch实现crnn+ctc实现不定长中文OCR识别
Python · 0 人关注
crnn.pytorch
Convolutional recurrent network in pytorch
Jupyter Notebook · 0 人关注
CTPN
Detecting Text in Natural Image with Connectionist Text Proposal Network
0 人关注
data_basics
JavaScript · 0 人关注
DCGAN-tensorflow
A tensorflow implementation of "Deep Convolutional Generative Adversarial Networks"
TypeScript · 0 人关注
ddd-angular-demo
JavaScript · 0 人关注
ddd-react-demo
0 人关注
Deep-Learning-Tricks
Enumerate diverse machine learning training tricks.
Python · 0 人关注
Detectron
FAIR's research platform for object detection research, implementing popular algorithms like Mask R-CNN and RetinaNet.
Shell · 0 人关注
docker
Docker Official Image packaging for Docker
Python · 0 人关注
DQN-tensorflow
Tensorflow implementation of Human-Level Control through Deep Reinforcement Learning
Python · 0 人关注
efficientnet-keras
Python · 0 人关注
experiments
Python · 0 人关注
GAN-MNIST
Generative Adversarial Network for MNIST with tensorflow
BrightLiao

BrightLiao

V2EX 第 90088 号会员,加入于 2015-01-05 16:28:25 +08:00
今日活跃度排名 11193
BrightLiao 最近回复了
7 小时 12 分钟前
回复了 qinrui 创建的主题 程序员 怎么避免自己写的代码变成屎山?
一旦你看你的代码快要变成山了,就得考虑是不是代码垒得太高了。拆分成两座或更多的土丘是大多数人的选择。

考虑:
- 从技术上看,有没有模块是非常复杂的,但是是独立的。如有,拆出去,专门给某个人或团队维护。
- 从业务上看,有没有两个业务本来就是相关性很低的,考虑拆分为不同的项目,交给不同的人维护。

现在大家在谈微服务,其实就是谈拆分,如何避免一个项目内的东西过于复杂。
很好的建议!我觉得团队甚至整个业务线、整个公司最好能建立一个缩写词库。DDD 中强调团队统一语言,这里的思路如出一辙!
74 天前
回复了 BrightLiao 创建的主题 程序员 我做过的一些 DDD 建模案例
真正的 ddd 其实和语言没什么关系,主要是来源于对要解决的问题的深入思考。当然,ddd 会对大家有一些技术背景要求,面向对象、函数式编程这些基本的技术需要掌握,solid ,cupid 这些好代码的原则需要知道。这些基础技能不熟悉,我们就会想要基于某个特定编程语言去学 ddd ,其实这是本末倒置了。
110 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@yule111222

聚合我也认为没什么不好(前提是设计合理),我也经常用,只不过在 smart domain 中聚合被弱化了,运行时就是一个复杂的对象图(在一个独立的内聚的领域里看,这本来就是事实)。如果要从 smart domain 对象图里面寻找聚合,一般而言,就是通过内存模型关联的一组对象。但是 smart domain 的灵活性在于可以透明的将内存关联变为数据库关联,甚至跨服务关联。

不过将 smart domain 和直接引用的聚合结合起来用,也是值得尝试的。事实上,我在文章中也提到可以尝试这样做。
110 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@yule111222

DDD 的要旨之一是建模人员是 Hands-on modeler 。所以,虽然可以有概念建模和领域建模的阶段,但是这只是建模过程的初始一小段,建模是要在整个软件开发过程中持续进行的(建模的结果绝不仅仅是发现了几个名词,还包括要深刻的建模业务规则,通过引入新的概念来抽象和简化规则)。事实上,如果初始的各种图没有持续更新,很快就会变成没用的或者误导团队的废纸。

如何做好建模呢? DDD 原书提到可以:

- 大声的建模(第 2.2 节):充分利用人类的语言天赋,大声的讨论、交流,最终得到一个统一的大家都理解的语言。“这个过程可以帮我们精练模型”。这是可以用 TDD 来驱动实现 DDD 的支持之一,因为在还没有代码的时候写测试,我们只能利用自己的语言能力去描述解决问题的过程。
- 绑定模型和实现(第 3 章): 在进行 DDD 时,不能将建模过程和实现过程分离,因为实现的一点点改变就意味着模型的改变。如果有人只关注建模而不关注实现,则他的建模没有用处,实际的模型将牢牢掌握在实现这个模型的开发人员手中。所以 DDD 的建模人员需要是 Hands-on modeler 。TDD 其实就是 Hands-on modeler 的武器。
- 通过重构加深理解(第三部分):在已有代码的基础上,从多个方向进行重构,尝试不同的建模想法,创造突破,从而得到更深刻的模型。TDD 产生的测试在重构的过程中为我们保驾护航。

TDD 的价值不只是在于测试覆盖,这只是它的一个副产物而已。TDD 的更大的价值在于可以用于改善设计(也即驱动 DDD ),我的另外几篇文章里面有一些思考:

- 从改善设计的角度理解 TDD: https://brightliao.com/2019/07/20/tdd-for-improving-design/
- 从改善设计的角度理解 TDD ( 2 ): https://brightliao.com/2019/08/18/tdd-for-improving-design-2/
- 好代码的五个特质 - CUPID (基于领域的章节): https://brightliao.com/2022/05/24/5-properties-of-good-code-cupid/

初始阶段进行一定程度的概念建模和领域建模是有用的,但即便在这个过程,TDD 也可以帮助我们提取和改善领域模型,除非我们的目标只是产出一个不知道是不是可以实现的设计文档(而不是一个可运行的 MVP )。从整个开发过程来看,在比初始阶段长的多得多的开发时间里进行建模,TDD 是有很大作用的。
110 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@yule111222 我一般的做法是用 TDD 来驱动复杂场景的模型设计,从而尽可能丰富领域模型,同时还顺便把测试加上了。所以,我会觉得用 TDD 可以驱动实现 DDD 。(简单场景的话,凭经验进行设计就搞定了)

打一波广告,最近刚开源了一个用于进行 ETL 开发的工具和库: https://github.com/easysql/easy_sql
有兴趣的同学可以研究一下里面的领域模型设计及测试(目前有 80%+的测试覆盖率)。
110 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@yule111222
聚合的问题在于粒度难以把握。现在大家都倾向于用小聚合,那么多小合适呢?之前的小聚合,是不是可能由于聚合内的实体逐渐变复杂而需要拆分呢?
测试更加不是一定要有聚合的理由。如果逻辑拆分合理,每一个实体应该都有自己的业务能力。测试应该针对每个实体的公开 API 来测试。如果直接对聚合上面的 API 来测试,则会把分散到各个聚合内的实体的业务逻辑一并测试到,从而导致需要覆盖的场景特别多特别复杂。

以上是个人的理解。
111 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@yule111222 欢迎回来分享使用经验啊!
111 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@jamel
分层架构的问题是,容易让开发人员把注意力放在分层上(导致领域模型抽象不足),而忽略了领域层建模才是 DDD 的核心。Smart Domain 可以把大家的注意力转移到领域层建模上。
就像 Eric 说的 DDD“远远不只是 ‘发现名词’,业务活动和规则如同所涉及的实体一样,都是领域的中心… 当我们的建模不再局限于寻找实体和值对象时我们才能充分吸取知识… ”。

其实,在分层架构下,对于合理的分层,现在的框架都有很好的支持,基本上都是利用框架的能力实现了。这也是应该弱化分层的理由之一。
111 天前
回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
@jamel
Smart Domain 是作者对这一 DDD 实现方式的命名。是一个新词。第一句话里面有提到。

至于文献,目前应该是没有的。其实工程实践类的专有文献一般比较少,毕竟不是科研。比如 DDD ,可能也找不到啥专门解释它的论文。有关工程实践类的书倒是不少,也许八叉后续会写本书来介绍 Smart Domain 吧。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2806 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 16:07 · PVG 00:07 · LAX 08:07 · JFK 11:07
Developed with CodeLauncher
♥ Do have faith in what you're doing.