DDD领域驱动设计

分析了做过的一些项目（基于经典DDD），觉得应用CQRS的场景还是蛮多的，特别是当出现模块之间出现相互依赖的时候，我这里说的应用场景不是为了保证查询数据的一致性，而是由领域出发自然而然的过程。举一个例子：ERP中的物流或供应链管理会有销售模块、采购模块、库存模块、财务模块等，

infoQ播放了DDD的创建者Eric Evans最新录像，谈了关于如今新技术对DDD的影响：Eric Evans on

我认为，任何业务可以描述为： 1，时间，2，场景（上下文），3，角色（party），4，主题(事件启动，事件源、动机)，5，行为（事件步骤，含中间状态），6，结果（状态持久化）

传统面向对象定义已经过时，过去定义已经不能满足新语言新思想的发展，来自A Proposal for

从2004年DDD诞生以来一直做领域驱动方面的实践，业务建模的过程可以说是一个痛并快乐着的过程，对于CQRS，很早就想写点什么东西，CQRS引入了对象状态、事件溯源（Event Sourcing）、快照（Snapshots）和事件存储（Event Store）等概念，

需求描述是这样的：crm系统中。“潜在客户”归档后变为“客户”。这个“归档”需要创建一个“客户”，并删除对应的“潜在客户”。新的“客户”对象的属性值多数是来源于原来的“潜在客户对象”。 这个Archive是一个业务方法，那么它应该写在domain层

发帖功能为什么不属于DDD的业务？

基于Event Sourcing模式设计的模型如何处理模型重构？ 问题背景：ddd的核心是聚合，一个聚合内包含一些实体，其中一个是根实体，这个大家都有共识；另外，如果将ddd与Event Sourcing结合，那就是一个聚合根会产生一些event；那么这里

目前DDD关于概念，设计思想讨论了比较多。但在编码过程中还是涉及到了一些问题： 实体类中如果有个值对象的列表，那我要获取这个列表应该怎么做？ 如账户实体中的角色列表： List getRoles(); a. 一种方式在实

转眼间，上jdon也两年了，从一个刚毕业找不到工作的D丝，终于可以约略了解banq的思想了。回忆起通过jdon学习架构之路，当然首先要感谢banq对我的巨大帮助。每当我对软件设计开发产生疑惑的时候，最终总能从jdon获得帮助。然而也有一些小遗憾，banq的知识面广，技术研究深刻，而且

首先我们开发 Aggre 类 User cqrsnode框架主页https://github.com/brightha

之前大家也都对图书馆借书还书的例子讨论很多了。所以业务需求描述我就不多说了。直接贴代码吧。下面代码的实现基于我自己开发的一个EventSourcing框架，继承自EventSourcing类的表明是一个事件源。

信息系统中，我根据分析得到了如下的实体/值对象/仓储等概念名称。 Info 信息实体（根）InfoState 信息的状态，是个值对象。infoRepo 是Info的仓储对象infoFactory

function Info(id){}

本来我想做DDD-NODE框架，但是发现不太可能，所以我分理出了能够简化开发的东西。 Repository 中能做的就是事件机制和一些约定规范。 Entity 能做的也是事件机制和一些约定规范。

当前pinterest很受大家喜欢，但是这个网站的里面有个功能很有意思，"boards"的设计，不知道如何做。当列出来某个人的所有的boards的时候，比如他有“衣服”，“内衣”等boards，每个boards可以显示5张图片，其中一张叫cover（封面），如果设置某个图片做封面，也