• 先说说之前几次DDD项目失败的案例,其实也不能算是失败,只是没有领会DDD的思想。 之前的DDD是建立在数据层之上的,首先是每张数据表对应一个数据实体,每个数据实体由泛型的DAO管理,DAO又被数据上下文继承以实现事务,这就构成了数据层,业务代码是写在Da
  • 网上书店是采用DDD设计思想构建的一个应用系统示例,实现网上书店的常用功能:包括浏览书籍、挑选书籍、提交订单、查看订单、自动折扣、处理订单、取消订单等。未登录用户可以浏览和挑选书籍;已登录用户可以提交和查看自己相关的订单;管理员可以处理订单。经过业务抽象,即使是这样一个简单的业务场景也包含了 icon
  • 2013-01-11 10:18 "@thinkjava"的内容命名是有些笼统 ... icon
  • 最近在看CQRS,找了一个DEMO,没有理解CQRS的读写分离体现在哪里?是指应用程序在写入和读取操作上分开的读写分离,还是指写入数据的DB和读取数据的DB分开这个层面的读写分离,如果是前者,那意义没有多大呀,仅仅是写操作和读操作在程序上分离了,降低了两个逻辑之间的耦合,这个意义不大呀,如果是后者, icon
  • 有界上下文BoundedContext在DDD是一个拓展的概念,在Evans经典DDD的书里应该是没有这个概念的,Jdon论坛上面的很少涉及BoundedContext文章。 就BoundedContext的设计上,提出几个自己的在这方面看法,抛砖引玉。 1、Bo icon
  • CQRS+Event Sourcing其实不但是一种全新思想,将可能颠覆Java或C#现有的编程体系。 使用传统JavaEE或Spring + Hibernate这样的框架,是无法实现DDD原始意图的,这个DDD创始人Eric Vans已经说过: icon
  • 个人认知中,面向对象(特别是面向对象的分析设计)建立在这样一种美好的愿景之上:将现实世界建模到计算机世界中,如此一来现实世界中大部分简单的需求变动同样可以在程序中较为便捷的实现。说的极端些,其实是在模仿造物主的现实世界而创造一个人即是上帝的“计算机世界”。那么,现实世界到底是怎样的呢? icon
  • 看到 领域驱动设计精简版 开始部分有一个图,一直不解1.图中的箭头是什么意思,是引用关系?2.UI层为什么跳过应用层会直接引用 Domain层,1数字位置?3. 2 数字位置,为什么有 两根箭头, 难道 a 、b 代表不一样,其它层也是一样,有多个框。[该贴被 icon
  • 1、如果我有一个魔法袋子,它能装下世界。袋子装的不是单一品种,要装什么东西还临时起意,想到啥装啥。我们的程序要怎样来表达呢?2、实体又是什么,看的见摸得着的就是实体吗?你能完整描述一个实体吗?如果不能,那么有什么机制可以轻易改动你的实体模型,而不改变原有的实体呢?3、世界是错综复杂的 icon
  • 看了flyzb 的对领域驱动设计的初步认识博客 icon
  • 贴图:领域驱动DDD聚合体作为模块,聚合体外使用事件消息,聚合体内封装了状态,外部调用必须通过消息事件实现,而不能直接通过方法调用。[该贴被banq于2012-12-06 12:01修改过] icon
  • 首先感谢@banq上次的回复和具体实例 但是我不得不说。。 理论性太强了落实到代码层面 还是不知道如何去做。 这几天也在看书 和 讨论 以下的讨论也恰是我对DDD所有的疑问 ,请banq 和 icon
  • event sourcing 不能被滥用。我用single responsibility的例子来做个类比。当一个类可能因为两个原因变化的时候,说明不符合单一职责原则。需要重构为两个类。同理,如果应用中有两个方法调用,本质上是传递同一种消息,那么可以抽象出一个事件。换种说法,只 icon
  • 在看DDD时,说到 值对象不可以改变,于是就可以共享。如果 值对象相同就都可以保持对它的引用,达到少创建值对象。如下 假设,一个User 实体,Address是它的值对象 icon
  • 不知道其他朋友怎么想,我觉得jdon论坛里有些主题有点形而上学了,在设计的上建立了太多的概念,很难理解,应用于实践就更难了。比如DDD,我就不理解这种概念建立的实际意义。还是返璞归真,以最简单的,并得到验证理念构建范式,进而指导实践更有意义。在我看来,系统本身概念是比较简单, icon
  • cqrsnode教程地址 http://url.cn/6fMJ6scqrsnode开源项目地址: icon
  • 学了有两周的理论了, 网上也看了不少经验贴 包括ITEYE 与 INFOQ的不过大部分例子我个人觉得 都只是包结构和 类的定义层级 与传统贫血模式的区别 用白话说我的理解从思想上我觉得DDD是希望 把业务 形成细粒度的 模型 ,模型里包含的 icon