• DCI是数据Data 场景Context 交互Interactions的简称，DCI是一种特别关注行为的模式(可以对应GoF行为模式)，而MVC模式是一种结构性模式，MVC模式由于结构化，而可能忽视了行为事件。我在
  • 去年我们讨论了很多关于异步，伸缩性架构的主题。近期我们也讨论DCI的一些主题。我就DCI，DDD以及领域事件说说自己的想法。 领域模型和领域事件本站已经讨论了很多，本人就略过，下面我结合本人的亲身经历说说关于DCI架构的一些想法。 <
  • 有界上下文BoundedContext在DDD是一个拓展的概念，在Evans经典DDD的书里应该是没有这个概念的，Jdon论坛上面的很少涉及BoundedContext文章。 就BoundedContext的设计上，提出几个自己的在这方面看法，抛砖引玉。 1、Bo icon
  • 2013-01-21 08:32 "@banq"的内容如果在这里引入“事件”概念可能就很清晰了，实体 值对象 、服务 和 icon
  • 我知道的软件思想至今发展的主要过程：面向过程 －》OO－》DDD－》DCI 始终是一个进化的过程，OO解决了面向过程的封装，但他依然是基于静态的分析；DDD提供了面向应用业务的分析指导，但是他没有直接提供解决对象变化的指导；DCI提供了系统模型分析的指导， icon
  • Contexts are the new objects一文提出DCI架构中Context是一种新 icon
  • 我JDOM上看了bangq关于DDD模式的设计思想，上面提到了关于聚合根的概念，还是不太能理解，请哪位高人举个例子吧。 icon
  • 如果保证更新俩个聚合对象的内部状态的最终一致性。 eg）jdonjive假设状况如下，必须同时更新俩个不同的聚合对象ForumMessageReply tmp;//create a ObjectForum1.addNewMessag icon
  • 这是一篇领域驱动设计Domain-Driven Design的简要总结：What I have learned a icon
  • 理论总是绕口的，特别对我这种懒人。只能说我懒，不能说理论无用。 那么标题“多个domain黑匣论”，简单的来说就是让领域层本身可以分为数个领域，下面以jsdm代码为例（记住：jsdm是nodejs框架还不成熟，能掌控的眼下只能是寡人，呵呵，推荐大家用ban icon
  • 我研究了一下DDD和DCI，我觉得适合大型和复杂系统，并不是什么都适合。 如果抛弃八股文的话，我认为DDD主要就是找领域概念和名词，然后弄一个类，然后大家都围绕这个通用名词和概念进行沟通。而不是技术层面的东西。我认为除了这个其他都是来回刷名词啦。 icon
  • DCI的从角色职责和场景的角度来理解业务感觉不容易，问几个问题？ 1、就我理解，上下文是其着承上启下的作用，每个业务过程的一系列行为都想象出一个特定的上下文，实践中是不是很困难？ 2、所有的业务交互行为都要发生在一定上下文（ icon
  • 需求如下： 登录之后如果没有建网站的可以通过下一步...方式创建一个空的网站。然后，可以创建空白页面，并在空白Page上添加自定义模块或系统模块，最后保存页面。用户也可以设置页面间的导航链接。 我 icon
  • 由于最近都在看经典的领域驱动设计一书，今天与同事讨论用户登录的业务场景时在实现方式上存在如下的困惑。 login的实现方法是否应该完全放在account的领域对象中，如果是的话，那么该account在何时被实例化？ 按照account id或usernam icon
  • 设计阶段，大家是怎么确定该使用module还是BoundedContext？ 领域模型，module，boundedContext关系是什么[该贴被axlfu于2013-07-04 17:14修改过] icon
  • 当应用程序逐渐变得庞大和复杂后，很多面向对象建模的方法都达不到非常好的可伸缩性。上下文图是一种通用目的的技术，作为领域驱动开发大家族的一名成员，它帮助架构师和开发人员管理他们在软件开发项目中不得不面对的形形色色的复杂性。与其他广为人知的DDD模式相比，上下文图可以应用在任何软件开发的场景中， icon
  • 看了一下DDD 苦于英文很糟糕 对BOUNDED CONTEXT不是很理解，哪位大虾可以帮忙详解一下，谢谢！ icon
  • 在Cargo的例子中，Voyage被做为一个实体引入进域模型, 但是在Cargo的例子中，Voyage是个非常简单的实体，只有只读的操作。在实际的生活中，我感觉Voyage肯定不是这么一个简单的实体，很可能有一个已经存在的专门的系统在维护。在Cargo系统中包含的Voyage应该是外部系统中的一个映 icon