• 这是来自drdobbs的Dino Esposito文章。在领域驱动设计提出后这十年，DDD已经证明对于某些复杂项目是有效的，为实践提供了适当的指导。 大约十年前，Eric Evans提出新的软件开发方法：领域驱
  • 其实这个观点我已经在“单元测试中的“单元‘如何定义？”中谈及，大概标题比较极端，吸引不少人兴趣，我再有逻辑的分析一下。 首先，我们必须
  • 这是来自Scala语言的TypeSafe公司的Dean Wampler在五月上旬React 2014大会上的演讲，演讲从面向对象范式 DDD领域驱动设计到函数编程范式。最后试图论证Akka是DDD最好的实现，虽然我个人对该观点有保留观点，但是想将大意翻译一下分享其一些精彩观点。原文PDF点击 icon
  • 让程序变得可推导，关键是对可变状态的围剿，纵观业界有三种方向：1. 通过函数式语言让不变性成为语言的默认特性，这样可变状态变成特例。这种方式会让程序员尽量不用可变状态，就是没办法回避也会努力花力气做好做完善。 2.让可变状态变成编程的核心，也就是说 icon
  • 这是一个Akka实现reactive DDD开源项目，点按标题进入，相比传统架构， DDD模型能够划分复杂的业务领域为可管理的部件，从而考虑到可扩展性和一致性的要求。这意味着，它带来的有界上下文，事务边界和基于事件通信的DDD和CQRS等概念能够极大地推 icon
  • 这是来自ScalaDays 2014大会上有关如何使用DDD EventSourcing/CQRS和Akka构建一个reactive的微服务应用系统的演讲，大意如下， icon
  • 点击标题进入 icon
  • Cribbb是一个使用DDD聚合根和领域事件Domain Events概念开发的PHP开源通知框架：cribbb/cribbb · GitHub icon
  • 估计2008年就从Jdon里面看到ddd了， 中间也看过很多DDD方面的帖子。 但是至今还是一知半解。 DDD中文名为“领域驱动设计”。看似简单的6个字， 确让很多人彻夜难眠，纠结无比？ 今天又看了一遍：领域驱动设计之我见 http://ww icon
  • 大家好，对于领域驱动设计开发来说我是一个新人，目前我在项目中强制自己实施领域驱动设计开发，为的是让自己能快速理解领域驱动设计并在开发中运用自如，但实际结果是处处都是问题，手里有两本书，但看了之后感觉问题更多，下面我问几个我目前最关心的问题，希望在此路上已有成就的道友能帮我一把。 icon
  • 这是abdullin使用Go语言实现一个DDD项目的实施过程日记，项目日记地址：http://abdullin.c icon
  • 以下是我关于经典DDD的简单理解：在经典的DDD中，大量使用领域服务 Domain Service 和 Factory 来修改聚合根。复杂的聚合根创建使用 Factory，将Factory 所需的参数全部传进去，Factory内部进行资源调配，包括逻辑验证，仓储 Repository icon
  • 领域驱动开发都是以模型作为开发的核心，随着需求理解的深入，对领域也会逐渐的扩充和舍弃无用细节。看到这个方面，我忽然想起以前没接触领域时候，与客户谈需求时，都要给客户提供一个原型，一般都是WEB页面展示，或者是CS系统的展示，里面囊括了需求中的功能。 icon
  • Monolith(整体型)系统其实不一定很坏，微服务可能会复杂化，微服务的好处如代码的自主权、做好一件事以及克服包依赖在整体型系统中也能做到， icon
  • 12306并没有想办法出来去忽悠大家，是咱们自己把自己忽悠住了。 icon
  • 请点标题进入，我的浅见而已，希望对一些童鞋有帮助。[该贴被brighthas于2014-08-12 13:56修改过] icon
  • 有个项目 业务逻辑大致是这样的。 项目主体是委托单 可以按业务需求不同。委托不同的业务服务。委托单和各种不同的业务服务单据都是实体对象。 看起来委托单是聚合根，因为所有其他业务单据的执行情况都会影响和反馈到委托单上来。委托单的领域模型聚合的里面包含这些个 icon
  • Node.js CQRS 框架 发布 0.6.5 参看： https://gith icon