声明： 本文已经首发于InfoQ中文站，版权所有，原文为《领域驱动设计与实践》，如需转载，请务必附带本声明，谢谢。 InfoQ中文站是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon 、线下技术交流活动QC

在上一篇文章《.NET应用框架架构设计实践 - 概述》的评论部分，有网友提出了一个在面向领域驱动架构的实践中比较常见的问题：“DDD使用聚合根访问，那例如那些通用查询如何实现？难道都要经过聚合根多步得到么？DDD如何实现关联表的查询，例如3表关联查询？”这个问题比较泛，涉及的内容也比较多，我就单

每位从事IT技术的人员一般都会关注在某一个特定的平台，这个平台能够提供你需要交付给客户项目或者产品的能力。我想市面上最主要的企业级应用平台主要有： 公司 主要语言 框架或技术 开发工具 软件产品 云产品 微软 C#/VB.net .Net Framework Visual Studio, Blend Windows, SQL Server, Office SharePoi

好久没有写文章了，最近比较忙，另一方面也是感觉自己在这方面没什么实质性的突破。但是今天终于感觉自己小有所成，有些可以值得和大家分享的东西，并且完成了两个可以表达自己想法的Demo。因此，趁现在有点时间，是写文章和大家分享的时候了。  首先给出这两个Demo的源代码的压缩包的下载地址，因为之前有博友说他没有装VS2010而没办法运行Demo，所以这次我分别用VS2008和VS2010实现了

一、问题描述 1、用户从图书馆借书 2、用户把书还给图书馆 二、问题分析 1、这个业务里面有几个角色？ 明面上，有用户（借书者）、图书馆、书三个。似乎只是简单的用户进图书馆-》拿书-》走人。 但是，有到图书馆借过书的人都知道，借书的流程应该是 进图书馆=》拿书=》登记=》走人。 是的，少了一个步骤，登记！！！！！！！！！！！ 也就是说，在不知不觉中我们少了一个角色：图书馆管理员！ 因此，业务里面的

由于项目需要，在办公室抱着领域驱动设计这本书啃了一星期。今天突发奇想想写个学习总结。于是乎就拿前段时间大伙儿都在讨论的银行转账问题来练练手，第一次接触领域驱动设计，有不妥的地方请大伙多多指教。 一、问题描述 实现银行账号汇款功能。 核心业务：将账号A的若干资金转到账号B上。 设转账金额为M(下同） Amount:账号资金 二、问题分析 1.账号A:账号A按照资金转出规则处理M 2.账号B:账号B按

 这篇博客就从我的一个同事说起。  阿广：一个很有经验的程序员，我很佩服他，大概半个月前离开研发中心，去产品中心做需求。在做需求期间应该对领域知识感触比较深，一次聊天聊到了我们感兴趣的知识。 回头看我们的聊天记录的时候，感到自己在这段时间进步了不少，故以此文鼓励自己继续前进。  一、部分聊天记录如下：    阿广 10:22:

经过上篇【讨论】“转账功能”引发的“谜团”的讨论，获益良多，首先先感谢各位博友的看法，真是醍醐灌顶，在细品评论的同时，我觉得很有必要结合自身对各位博友评论的理解总结出一些什么来反馈一下，所以特此开多一篇文章来，集思广益。   和上篇做法差不多，通过不同做法对比来展开讨论，要注意的是本篇的伪代码完全和上篇没有承接关系，内容上也没有绝对的联系。

    听说DDD-“领域驱动开发”已经很久了，园子里面已经有不少大牛写过博文介绍，但我一直没有尝试过，直到今年公司的一个项目出现数据库移植，原来的业务逻辑都写在SqlServer的存储过程中，现在要移植到PostgreSQL中，才真切的体会到，再继续走“表驱动开发”的模式，没有好前途了。于是，花了几个星期，来实践一下领

关于图书管理系统的业务大家都应该比较了解了，主要的核心业务是：用户持图书卡去图书馆借书或还书。下面是他们几个人讨论的最经典内容，我特地整理出来供大家可以集中的观看他们的讨论。其实在我看来更是一种世界观与世界观的碰撞，我想借此表达的思想是：代码不一定要写很多，但是思维方式或者说世界观一定要正确，否则方向错了，就什么都错了。 以下是讨论的详细内容：Jdon007: 1、借书人(Reader

      MVC架构模式是近年来编程世界里最长被提及的模式之一，Model-View-Controller(模型-视图-控制器，MVC) 模式将你的软件组织并分解成三个截然不同的角色： Model 封装了你的应用数据、应用流程和业务逻辑。 View 从 Model 获取数据并格式化数据以进行显示。 Controller 控制程序流程，

本文将重点介绍Microsoft NLayerApp的领域模型层，这涉及到Domain.Core、Domain.Core.Entities、Domain.MainModule以及Domain.MainModule.Entities四个项目。Domain.Core项目包含了基本接口的定义以及规约模式（Specification Pattern）的实现；Domain.Core.Entities则包含了

  领域驱动设计，挺好的，新做的一个商城也是基于这个思想来进行开发的。由此，想和大家一起分享一下应用这个思想在做项目中的一些领悟与经验，正好也能和大家一块探讨DDD，使我们能更好地理解领域驱动设计。 这一篇就和大家分享一下我使用的一些用于架构与建模使用的组件。     在这里，个人推荐使用一个开源的DDD框架组件：SharpArch.d

 今天我们通过一个“超市收银”业务来作为我们的示例（虽然这个示例看上去不太正常，但是它确表述我们所需要的）。我们将从业务分析到业务建模然后最后的编码来用“面向领域对象”的方式来做我们的项目。 好，我们开始吧！   一、业务分析   大家都去超市买过东西，对超市收银业务都比较熟悉。什么？你不熟？好吧，那我们找个收银员给大家

    最近面向领域的知识挺火，我也来插一腿。说说我平时做项目时候用到的开发方式，以下代码为伪代码，主要展示一下我现在的开发方式供大家讨论，系统中不考虑持久、UI、AOP和IOC等方面内容。     说到.NET社区的“开发方式”就不得不提一下Petshop了，可以说Petshop真是影响了.NET的一代人。以至于

上篇文章引起不少有价值的回复，我也学到不少东西，谢谢大家。 　　在此对上篇做下补充说明： 　　1，因本人毕业以来从事的项目全是业务逻辑复杂的企业应用软件，ERP，SCM，HRP，CRM……，这种系统，如Martin Fowler在PEAA一书中所说，是适合使用Domain Model的，上文和本篇讨论的都是基于这样的场景和前提。 　　2，正如一哥们回复中说的，天下没有绝

做不完的应用软件 　　我爸是个乡村小学教师，对我所从事的软件行业一无所知，但是他对我的工作稳定性表示怀疑：“你这做软件的，要是有一天软件做完了，你岂不是要失业了？”也许他想起了他作为老师的情况，教完一批学生，下一批又上来了，一茬一茬的。于是又问我：“你们是不是一个软件接着一个软件做？”我回答他：“不是，就一个软件，好几十个人得做好几年呢。

前面一篇文章介绍了我设计的基于“事件”驱动的领域模型的基础框架的设计起因和设计思路。基于这个框架，我们领域模型中的所有领域对象有如下几个特点：任何一个领域对象是“活”的，它不仅有属性（对象的状态），而且有方法（对象的行为）。为什么说是“活”的呢？因为领域对象的行为都不是被另外的领域对象调用的，而是自己去响应一些“事

从去年10月份开始，学了几个月的领域驱动设计（Domain Driven Design，简称DDD）。主要是学习领域驱动设计之父Eric Evans的名著：《Domain-driven design：领域驱动设计:软件核心复杂性应对之道》，以及另外一本Martin Flower的《企业应用架构模式》，学习到了不少关于如何组织业务逻辑方面的知识。另外，在这个过程中也接触到了一些开源的架构和一些很好的

之前发表了一篇博文，是介绍关于我心中的领域模型该如何设计的。点击此处下载框架源代码和Demo。但是大家可能由于没能直观的看懂我的设计思想而忽略了那篇文章，也不能怪大家，只能怪我不能很好的表达自己的思想。所以，为了更好的能和大家交互，能展示我的思想，我再写几篇文章介绍我设计的领域模型及背后的亮点。   首先先把领域模型的结构图贴出来，让大家有一个直观的感觉，然后再做详细介绍。 &nbs