• 建模原语:四象图 作者：achieveidea@gmail.com 命名：模型、结构特征、行为特征、场景（及其规约）。
  • 我个人认为：OO本质是逻辑分析。通过逻辑分析需求，寻求从需求到软件运行内部环节的内在一致性。逻辑分析是OO的元语言，正如它也是数学元元语言一样。逻辑分析是认识世界的基本手段，是软件建模分析的最基本的保障。 OO思维是一种逻辑分析思维，通过逻辑分析发现表达对
  • 在Yahoo的SOA讨论组一直持续着OO面向对象和SOA之间的讨论，涉及领域模型domain icon
  • 我来用简要的描述一下DDD和DCI的突破性思维。为什么需要DDD / MVC / DCI ，其实是对人类思维可控性的考虑。我们需要着重于DSL思维，要更加靠拢需求和用例。而DCI的提出让OLD DDD 重新考量，而让DDD提供了必要的几个概念，而这些概念也是为DCI框架提供的工具。 icon
  • 第一次在这里发帖，不太懂这里的排版。。。原文在此 去 icon
  • 业务需求：1. 一个客户可以有多套房子的房贷2.签署贷款合同以后要监控是否按照还贷计划表来执行3.自动还款，当多套房贷时，一次还款可能包括多个房贷的额度，需要自动匹配4.可以提前还款5.可以延长或缩短贷款的时间6.利率可以调整7.滞纳金的问题< icon
  • 看了这个帖子 http://www.jdon.com/jivejdon/thread/37712/15，深受启发。 因为我也正好碰到这个问题。比如一堆分类，每个分类需要统计其下Product的数量。 这是我的回帖 icon
  • repository是针对聚合跟建立还是针对实体对象啊？比方说员工是聚合跟，考勤记录是员工的一个属性，是个list；我是对应聚合跟 Employeerepository我想添加一条考勤记录的话，employee = Employeerepository.ge icon
  • 大家好，又是一年春草绿啊，祝大家步步步高升，少摸电脑多触人。我现在还是不能理解，DDD中的实体和数据库中的实体，有什么区别和联系，我的感觉，DDD的实体去掉其中的方法，留下的就是数据库的中的实体，不知道，我这个理解对不对呢，如果是这样，那我反过又有什么不可以呢，先花ER图，再为实体添加方法， icon
  • 我在仿照领域驱动设计重构了系统,当我在添加缓存功能的时候发现有点难度,希望老师指点.我举一个例子:用户--角色 多对多关系用户和角色都属于聚合根,因此应该都同时对应的repository,同样具有对应的缓存集合.当从数据库中加载用户和角色的时候,该怎么维护其中间关联信息呢?< icon
  • 如题，如果是聚合根的话，CRUD是通过仓储来处理的可以理解，但是如果是被聚合的内部实体，他没有仓储，他的CRUD在何处处理呢？直接在聚合根的部位进行么？那不是就在领域层加入了持久层的操作了么？ 我想了一下，应该是在对聚合根进行持久操作的时候 icon
  • 今天详细看了一个帖子：http://www.jdon.com/jivejdon/thread/39844，该例子是以图书借阅系统作为例子讨论如何进行建模。看完这个帖子感觉真的受益匪浅。下面我也想表达一下我的个人看法。 其实我觉得四色原型和DCI早已经明确给 icon
  • 领域驱动设计 Layered Architecture 图中， UI LAYER 直接使用 DOMAIN LAYER 那条线怎么理解？ icon
  • 这个问题貌似没人讨论，软件设计思路很好，但是无法体现在纸上的话也是白费，大家有什么看法？有模板么？ icon
  • 我正在开发一个可视化网站制作系统，当然和DW不同，这个产品有其特别之处。不过我们抛弃产品本身，我来说说我采用DDD DCI的一些概念的开发经验，希望Banq大哥和大家指正。 这个项目加入了两个角色，类似DCI中的角色扮演，有 Guest 和 Manager icon
  • 初学DDD和DCI，总感觉有点小困惑，来请教一下各位老师。问题如下三点： 1、DDD通过找聚合根来划分领域，这不有点像是模块的划分吗，准确的说是一种更细粒度的模块划分吧？ 2、若有把DDD和DCI结合起来，那么C icon
  • 一个按照合同分期付款的需求，现在我自己理解的划分： 实体：合同（聚合根），合同付款计划，合同付款核销记录实体：客户（聚合根）实体：付款记录（聚合根） 值对象：合同状态，属于合同 < icon
  • 是否通过根追溯到内部对象？比如：A B C 三个 entity，那么A为根 还伴有一个 D是A的仓储那么，得到B 和 C 是不是通过根A ？ icon