摘要：UnitOfWorkUnitOfWork是一种有状态的、用例级别的对象。如果不采用ORM是不会使用UnitOfWork模式的，RepositoryRepository是一种特殊的领域服务，因此是无状态的、全局单例的。Repository和UnitOfWork之间的关系在一个用例中，一个UnitOfW... 阅读全文

摘要：Design is not just what it looks like and feels like. Design is how it works. 阅读全文

摘要：下面是《实现领域驱动》的作者给出的一段话：You can implement DDD if you have：A passion for creating excellent software every day, and the tenacity to achieve that goalThe e... 阅读全文

摘要：如果采用这种模式，模型会在不同的逻辑层之间传递，以向内传递为例，模型的状态变化是由外向内的不同逻辑层负责修改的，因为这种模式下模型的封装性是很差的，架构和框架要做到：清晰的表达每个逻辑层该如何使用和修改模型状态。 阅读全文

摘要：背景大师们让我们多使用“值语义”的对象（并非一定是是值对象），我们工作中也没有少使用（int、bool、date等等），只是大多数人都没有多的自定义“值语义”的类型（我也其中之一），本文不说其它的，就谈谈“值语义”的优点和缺点，以及：如何更好的使用值对象，说白了：让优点大于缺点。值对象优点更细粒度的组织代码（小规模的模块化）。安全、无副作用。缺点实现成本高。修改成本高：a = a.modify(xxx)。就目前来看，“缺点”视乎占据了“优势”，让我们增加一个“优点”来个逆转：“值对象” 对应的 “UI 组件” 支持。如果自定义的“值类型”能像原生值类型（int、bool 等）一样，在架构的个个 阅读全文

摘要：大家都能达成的两个共识是：概念模型中，聚合之间充满着关系（双向）。对象模型中，根据有用性、性能和成本等因素考虑，保留某些必须的关系。备注：读写分离有利于更好的表达关系，因为某些关系在读取的时候需要，而且模型需要扁平化，某些关系在写入的时候需要，模型需要立体化。 阅读全文

摘要：首先我在一家老板有点关系的小软件公司带领一帮工作一两年的程序员做项目，这里要特别强调的是做项目(差不多是外包，只不过客户群体比较固定)，项目就是今天项目A是这个逻辑，明天项目B是那个逻辑，两者之间的业务基本没有什么可复用的地方。 在这种项目上实施ddd，感觉非常痛苦，比传统的开发模式要花费更多的成本。举个简单的例子，对一条信息进行编辑， 用ddd的话，可能要经过3-4次的对相同内容的赋值操作，尤其是在引入领域事件驱动的情况下更是如此。而传统开发模式可能就一次赋值就提交到数据库中，尤其是这些项目的90%的功能都是基本的CRUD。所以我觉得这种没有很大持续性的项目(就是几个月做完验收后,可能再也不 阅读全文

摘要：文章列表Coding for Domain-Driven Design: Tips for Data-Focused Devs。Strengthening your domain: Aggregate Construction。 阅读全文

摘要：背景看了这篇文章：Coding for Domain-Driven Design: Tips for Data-Focused Devs，对 BoundedContext 的设计有了一点新的体会，记录下来，加强记忆。Sometimes All You Need Is CRUDNot everything in your app needs to be created using DDD. DDD is there to help handle complex behaviors. If you just need to do some raw, random editing or queryi 阅读全文

摘要：背景DDD中只有聚合根可以有仓储，仓储负责整个聚合持久化的相关生命周期，在不使用工作单元或POCO的情况下，我们可以让Order内部直接调用DAL操作OrderItem。我们也可以让Order跟踪所有OrderItem的状态，然后在OrderRepository内部操作OrderItem。如果我们采用了重量级的ORM工具，如：EntityFramework，事情会不会变得简单呢？使用EntityFramework持久化聚合关键思路：双主键。示例聚合这里以订单和订单项为例。Order管理OrderItem 1 public void AddOrderItem(OrderItem ... 阅读全文

摘要：背景实体能否处于非法状态吗？如果实体只承担其作为实体的职责，我不认为实体可以处于非法状态，如果您将实体在不同的分层之间传递，如：UI->Application->Domain-Data，那么这种情况实体承担的角色就当多了（职责过重），在这种情况下是允许处于非法状态的，也可以这么说：某个类型的实体角色是不能处于非法状态的，如同这个类型还承担其它角色，是可以处于非法状态的。参考文章http://www.cnblogs.com/happyframework/p/3158338.html。http://www.cnblogs.com/happyframework/p/3242183.htm 阅读全文

摘要：聚合跟和实体聚合根是实体。实体有生命周期，使用标识进行跟踪。聚合根是全局标识，由仓储或其它服务负责其生命周期。实体是局部标识，由聚合根负责其生命周期。为什么能应对复杂度？纵向、横向、时间维度的合理划分，如：分层、分聚合、分上下文、迭代（分时间）。什么是值对象？首先值对象是”不可变的“，也就是说值对象是”原子的“，String是值对象，其聚合了Char列表，因为常见的关系数据库内置了对String的支持，因此映射起来比较容易，简单的值对象也被ORM所支持（拉平），但是集合形式的值对象，就需要自己映射了，而且要保证”集合本身“是值对象。 阅读全文

摘要：背景一个实体在不同的上下文中具备不同的职责，如：产品在“生产完成上下文”中具备的一些职责，在“质检相关上下文”中具备另外一些职责。四色原型、DIC和“UML事物模式”在不同的维度阐述了这一情况，在代码层面到底该如何表达呢？本文给出了一些思路。六种实现方式因为：MI（Manufacture和QualityTesting）和Context（ManufactureContext、QualityTestingBeginningContext和QualityTestingCompletingContext）都是空实现且每种风格中的代码都一样，后面只给出跟PPT和Role相关的代码。第一种：未显式体现角色 阅读全文

摘要：背景一个类型可以充当多个角色，这个角色可以是显式的（实现了某个接口或基类），也可以是隐式的（承担的具体职责和上下文决定），本文就讨论四个角色：数据模型、领域模型、视图模型和命令模型。四个角色数据模型：面向持久化，数据的载体。领域模型：面向业务，行为的载体。视图模型：面向UI（向外），数据的载体。命令模型：面向UI（向内），数据的载体。这是四种角色，可以由一至四个类型来承担，具体选择几个类型需要考虑项目的上下文，但不同的选择对编程的要求是不同的，下面举几个例子。数据模型和领域模型采用统一个类型，采用EntityFramework进行持久化。这种设计毫无疑问对这个类型是有侵入性的，即使采用了POC 阅读全文

摘要：背景系统开发最难的是职责的合理分配，或者叫：“如何合理的组织代码”，今天说一个关于这方面问题的示例，希望大家多批评。示例背景参考数据字典需求OrderCode必须唯一。Total = Sum（Subtotal）。订单有三种状态：【未提交】、【待审核】和【已审核】，合理的状态迁移有：【未提交】----》【待审核】和【待审核】----》【已审核】，只有处于【未提交】状态的订单能修改。订单和订单项中的状态必须合法，规则自己定义。示例实现项目结构Application：应用层，负责领域逻辑的封装。主要角色：ApplicationService、CommandHandler。Boostrap：启动管理层 阅读全文

摘要：@汤雪华验证是为了让数据符合要求。各个层的验证是为了确保传递给各个层的数据符合当前层所需要的数据的要求。@小学僧db model的验证主要是为了保证数据完整。domain model的验证主要是为了保证业务完整。view model的验证主要是为了用户体验。领域模型能否处于非法状态？如果采用领域驱动，我不会让领域模型处于非法状态的。如果采用贫血模型，我会。 阅读全文

摘要：背景见过很多框架（包括我自己的）都会在实体的定义中包含一个IsValid()方法，用来判断实体的合法性，是否应该这样设计呢？本文就这个问题介绍一点想法，希望大家多批评。实体能否处于“非法”状态？实体是否应该包含IsValid()方法的深层次问题是：“实体能否处于非法状态？”。我们来定义一些术语，接下来我就引用这些术语：A模式：实体允许处于非法状态，但是实体要包含一个IsValid()方法进行校验。B模式：实体不允许处于非法状态，业务逻辑必须保证这一点。关于A模式我不想多说了，A模式本身没有问题的，今天重点说说如何实现B模式。如何实现B模式？最好的说明就是写一个例子，下面是我们例子的需求：xxx 阅读全文

摘要：“模型、状态和行为特征、场景”和“四象图”，建模观的命名与立象。建模原语:四象图作者：achieveidea@gmail.com命名：模型、结构特征、行为特征、场景（及其规约）。释义：模型，描述事物为一组时间函数，蕴藏了与事物相关的所有事实。特征，从模型上剥离的一组时间函数。特征分为两大类，一类是结构特征，一类是行为特征。场景，模型凝聚相应的特征持续一段时间，描述一段时间内与模型相关的事实。场景中隐藏的一些规则、约定，称之为场景规约。用法：一笔一纸，一横一竖，四象顿生。一象画景，三象画物，物在景中。二象画形，四象画神，形神兼备。万象入画，浑然一体，一目了然。注：第一象限画景，即描述场景；第三现 阅读全文

摘要：IntroductionMany approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping is a general purpose technique, part of theDomain Driven Design(DDD) toolkit, helps the architects and developers manage the many types of complexity they 阅读全文

摘要：背景会有朋友问我为啥用命令模式（Command Pattern）组织应用层，先看看MartinFowler咋说：http://martinfowler.com/bliki/CommandOrientedInterface.html。总体来说我有三种模式来组织应用逻辑：http://www.cnblogs.com/happyframework/archive/2013/03/27/2986021.html，之所以采用命令模式，是因为命令模式有如下几个好处：拦截（AOP，不用动态代理）、发生到远程（不用为每个应用逻辑开发WCF服务）、异步、离线、排队。一些资源拦截：http://www.cnblo 阅读全文