DDD领域驱动设计

Tutorial – Getting started with

How To Write A Repository 仓储Reposi

前一段时间我用面向的对象的方式来写我自己的一个小JEE应用程序，业务逻辑比较简单,就是一些“增删改查”的工作，我一直想把我的小应用程序纳入实际应用中，后来在JDON上看到了大家关于DDD的困惑，我也遇到了业务逻辑该写在什么地方。 经过一番思考之后，我设计出了一个新的编程方式，我认为已经从理论

转一篇领域驱动设计的文章,在探讨下设计领域驱动设计实践

（一）抽象之美OO直接翻译过来就是“面向对象”，它作为一种编程思想可以说是划时代的进化。虽说可能不是传说中的“银弹”（解决软件太复杂的万能灵丹），但是却能使挣扎在“焦油坑”中，那些绝望而无助的受难者猛然间看到希望。写《人月神话》的时候OO还没有出来，现在作者很可能对于这一项技术性的变革投以赞

  前面的帖子很绕，我反思了一下，基本赞同banq关于“业务领域”和“领域模型”的说法。好了，DDD锵锵三人行继续开会。  我在百度百科上查了一下关于“领域”的定义：

我经常用到一般都是STRUTS+WEBSERVICE 或者是SSH框架，我总是感觉写来去就是为了和DB打交道，利用CURD组织成画面的数据，我完全感觉不到业务逻辑是在SERVICE层，SERVICE根本不像对象，更像是一个函数库，对于WEB开发，业务逻辑明显是存在数据库里，而画面就是业务逻辑

context在实际的框架中，比如有个Context类，这个类应该是什么样子呢？Context对应一个用例，那么这个Abstract 类的Context应该是什么样子呢？ 然后，就是我想加入DDD DCI中的 实体类和值类型的类很好具体创建。那么

account 是一个实体。有存款，取款俩个行为。accountRepository 仓储类。有三个方法，新建账号，得到账号，更新账号。 有一个转账的业务。A到B。假设条件成立，A有足够的钱。 领域服

以下知识是关于领域驱动设计（DDD）的, 大部分摘自flyzb的思想,虽然在很多人看来并不赞同, 但我个人认为对我启发很大. 有兴趣的可以看一下. 我一直觉得不要盲目相信权威，比如不能一谈起领域驱动设计，就一定认为国外的那个Eric Evans写的那本书中的一些概念就一定是正确的，认为领域驱

该架构的核心思想是: 1. 领域模型好比是一个实心的圆球，圆球的表层就是领域服务（Domain Service），圆球内部由各个相互平等的，没有相互依赖的，通过事件消息完成相互协作的领域对象组成；2. 领域模型应该依赖于一个中央事件处理器，该处理器

按照DDD的思想， 实体是不应直接暴露set/get方法，而应该是暴露有实际含义的操作。但是实体之间以及实体与DTO难免存在拷贝的问题，一般会采用一些拷贝的工具类来实现，那么这里问题就出现了，如果实体不暴露set/get方法，那么拷贝的工具类是无法执行的。另外，对于hibernate这种OR

一个问题需要请教板桥老师：我在做DDD设计时遇到一个问题:(在做一个model.service和repository的问题) model 中业务类:BillMgr(账单管理，从repository 获取账单，内部排序等 --内部方法

/** 坦克大战DDD方式建模*/ // 游戏 实体对象 -------- 聚合的根function Game(){ var id; var map; // 1:1

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

以前写需求与设计时都是有将表结构和ER图写在文档里面，在学习DDD后我不想再这样写了，可是如果我不写数据表结构的话，难道把类图写到文档中么，客户能看懂，他不会听我去给他们解释。那种双方人马坐在一起讨论需求的场景太理想话了吧？我现在遇到一个客户，懂点计算机,跟他沟通需求的时候就老要跟我讨论表的