限定上下文BC

看了一下DDD 苦于英文很糟糕 对BOUNDED CONTEXT不是很理解，哪位大虾可以帮忙详解一下，谢谢！

Martinfowler的这篇微服务文章引发了软件架构方面的热烈讨论，“今天在软件架构方面，除了微服务这个名称没有什么新的”。现大意翻译如下： 微服务，是另外一个在软件体架构这个拥挤的街道上冒出的新名词

假设一个ProductSpeed有两个不同的构造器：

A Bounded Context does not necessarily encompass only the domain model. True, the model is theprimary occupant of the conceptual container. Howeve

这几天在看《impelment domain driven design》，很多都是语言层面的问题，就是说context Bounded，作者说context Bounded 所说的边界，是语言的边界，在context bounded 中有model，在context中的统一语言才有其特殊的意思。例

举个例子，一个交易系统：用户购买某个商品生成一笔交易可以抽象出，聚合根：交易，用户和商品是交易的属性那用户这个对象 那就不是聚合根，而是值对象？随着业务的发展，比如根据交易衍生出等级会员制度，那用户是不是也会变成一个聚合根CQRS中读缓存是缓存整个领域对象还是缓存值对

理论总是绕口的，特别对我这种懒人。只能说我懒，不能说理论无用。 那么标题“多个domain黑匣论”，简单的来说就是让领域层本身可以分为数个领域，下面以jsdm代码为例（记住：jsdm是nodejs框架还不成熟，能掌控的眼下只能是寡人，呵呵，推荐大家用ban

在Cargo的例子中，Voyage被做为一个实体引入进域模型, 但是在Cargo的例子中，Voyage是个非常简单的实体，只有只读的操作。在实际的生活中，我感觉Voyage肯定不是这么一个简单的实体，很可能有一个已经存在的专门的系统在维护。在Cargo系统中包含的Voyage应该是外部系统中的一个映

由于最近都在看经典的领域驱动设计一书，今天与同事讨论用户登录的业务场景时在实现方式上存在如下的困惑。 login的实现方法是否应该完全放在account的领域对象中，如果是的话，那么该account在何时被实例化？ 按照account id或usernam

设计阶段，大家是怎么确定该使用module还是BoundedContext？ 领域模型，module，boundedContext关系是什么[该贴被axlfu于2013-07-04 17:14修改过]

2013-01-21 08:32 "@banq"的内容如果在这里引入“事件”概念可能就很清晰了，实体 值对象 、服务 和

有界上下文BoundedContext在DDD是一个拓展的概念，在Evans经典DDD的书里应该是没有这个概念的，Jdon论坛上面的很少涉及BoundedContext文章。 就BoundedContext的设计上，提出几个自己的在这方面看法，抛砖引玉。 1、Bo

这是一篇领域驱动设计Domain-Driven Design的简要总结：What I have learned a

我知道的软件思想至今发展的主要过程：面向过程 －》OO－》DDD－》DCI 始终是一个进化的过程，OO解决了面向过程的封装，但他依然是基于静态的分析；DDD提供了面向应用业务的分析指导，但是他没有直接提供解决对象变化的指导；DCI提供了系统模型分析的指导，

需求如下： 登录之后如果没有建网站的可以通过下一步...方式创建一个空的网站。然后，可以创建空白页面，并在空白Page上添加自定义模块或系统模块，最后保存页面。用户也可以设置页面间的导航链接。 我

我研究了一下DDD和DCI，我觉得适合大型和复杂系统，并不是什么都适合。 如果抛弃八股文的话，我认为DDD主要就是找领域概念和名词，然后弄一个类，然后大家都围绕这个通用名词和概念进行沟通。而不是技术层面的东西。我认为除了这个其他都是来回刷名词啦。