面向对象的分析、设计、编码三种方法融会贯通，成为一个有机的整体，这个叫面向对象的方法学
来自：01｜DDD小传：领域驱动设计为什么这么火？
8 人划过
还有一点要提一下，我发现一些小伙伴喜欢统一用 XxxDomainSerivce 的方式给领域服务命名，这似乎有些拘泥了。我建议最好按照含义来命名，比如这里就用了 XxxValidator 的名字。
来自：11｜代码实现（中）：怎样创建领域对象、实现领域逻辑？
5 人划过
这四个字段常常被称为审计字段，可以用来进行安全审计和错误排查。作为一种最佳实践，我们在每一个表中都会包含这四个字段。
来自：08｜数据库设计：怎样按领域模型设计数据库？
5 人划过
任何多对多关联，总能用类似的方法，通过引入一个表示关联的实体，拆成两个一对多的关联
来自：06｜领域建模实践（下）：领域建模还有什么其他技巧？
4 人划过
在实现一些业务规则时，需要访问数据库中的数据，因此领域服务需要读数据库。而写库的功能通常可以由应用服务来做，从而减轻领域层的负担。有些伙伴喜欢把写功能也放在领域服务，从而使应用服务非常薄，这样也可以。
来自：12｜代码实现（下）：怎样更加“面向对象”？
4 人划过
在事件风暴里只列出主要的、足以用于表达和交流领域知识的步骤
来自：04｜事件风暴（下）：事件风暴还有哪些诀窍？
4 人划过
要在实践里真正贯彻“统一语言”的理念，我们可以从统一语言的“物质基础”和“实际应用”这两个方面来考虑。
来自：07｜领域建模原理：DDD领域建模和传统方法有什么区别？
4 人划过
是约束，必须在程序中的某个地方进行实现
来自：05｜领域建模实践（上）：怎样既准确又深刻地理解业务知识？
4 人划过
分层架构规定只能外层依赖内层，在今天讲的几层中，有一处可能会破坏这种层间依赖关系，你能找出来吗，有没有解决办法？
来自：09｜分层架构：怎样逃离“大泥球”？
3 人划过
事实上，直接“借用”系统中已经存在的机制，在短期内虽然达到了目的，但长期来看会导致概念混乱，这种做法是很多开发团队常见的错误。而错误的根源，就在于我们没有掌握一种优雅的方法，来处理不同概念的共性和个性。
来自：22｜泛化建模（上）：领域知识更抽象怎么办？
3 人划过
*精彩内容为该课程各文章中划线次数最多的内容
讲师
钟敬
Thoughtworks 首席咨询师、数字化转型与运营团队 DDD 负责人
编辑推荐
看过的人还看了
