HappyFramework（幸福框架）

摘要： PPT对应某个聚合。Des对应某个聚合或其它聚合内的实体或值对象。MI对应某个聚合。Role对应PPT（Data）在某个上下文（Context）执行某些交互（Interactive）的代理或装饰器。四色原型中的一些静态方法需要移动到仓储或服务中。 阅读全文

摘要： CQRS架构的选择？系统的分层策略？应用层的组织风格？是否采用EventDriven？这些统统和咱们讨论的话题没关系，换句话说：“无论您采用贫血模型或领域模型，您都可以选择之上的技术”。贫血模型和领域模型从OO的角度考虑，前者缺少“封装”，换句话说：“无论您采用贫血模型或领域模型，您都可以用好继承和多态”。封装带来的最大好处就是依赖性的降低和可维护性的提高。 阅读全文

摘要： 《精通.NET企业项目开发：最新的模式、工具与方法》《.NET应用架构设计：原则、模式与实践》《ASP.NET设计模式》《Microsoft .NET企业级应用架构设计》《领域驱动设计C#2008实现》《领域驱动设计与模式实战》《领域驱动设计》 阅读全文

摘要： 程序中的读写分离，具体表现为：读写使用不同的设计理念、不同的执行流程、物理上分布在不同的DLL。程序中的读写分离+数据中的读写分离，具体表现为：除了上边的要求外，读写数据库也是独立的，同步可以用Event或其它机制。程序中的读写分离+数据中的读写分离+EventSource+InMemory：除了上边的要求外，引入了EventStore、SnapshotStore、InMemory DomainObject的概念。 阅读全文

摘要： 仓储的职责仓储接口在领域层。仓储实现在基础设层。仓储的主要职责是处理聚合的和持久化相关的任务（ADD、UPDATE、DELETE、GET）。仓储不应当实现业务逻辑，如：ADD操作的前置条件（用户名必须唯一）。结论：如果是这样，应用层是不是最好不要直接用仓储，因为仓储没有封装业务逻辑，直接用可能会绕过业务逻辑。 阅读全文

摘要： TDD测试流程先写测试。后写代码。进行重构。TDD原则一次只测试一个类。一次只测试一个功能。TDD优势强迫你做出松散耦合的设计。强迫你站在用户的角度思考问题。作为负效果，你拥有了自动化测试。测试可以作为文档使用。 阅读全文

摘要： 第一步：配置外部工具第二步：使用工具选中“生成器配置信息（Domain.json）”，然后点击【工具-》HappyGenerator】进行代码生成。 阅读全文

摘要： 作为开发人员，你无时无刻不在做出决定，思考你的每个决定，给自己一个充分的理由，常见的决策如下：架构的风格。技术的选择。编码的风格。API的命名。模式的选择。变量的命名。语句的组织方式。算法的选择。 阅读全文

摘要： MI和MIDetail属于同一个聚合。MI和MIdetail不能持有对PPT的引用，只能存储其快照。PPT多数情况是一个聚合就一个聚合根；Description对PPT的描述，可以表示为一个标识引用或将Description做为值对象。Description多数情况是一个聚合就一个聚合根。Role多数情况可以视作一个领域服务。四色原型间的关系通过仓储进行导航。 阅读全文

摘要： 1. 过去的事情可以不忘记， 但一定要放下。2. 收敛自己的脾气，偶尔要刻意沉默，因为冲动会做下让自己无法挽回的事情。3. 无论什么时候，做什么事情，要思考。4. 永远不要给背叛过自己的朋友第二次的背叛的机会。5. 无论是谁，都有自己的限度。特别是信任。6. 懂得倾听别人的忠告。7. 别人说的记在脑袋里，而自己的，则放在心里。8. 尽量不要讲同事朋友的八卦。9. 偶尔也要现实和虚伪一点，因为不那样做的话，很难混。10. 坦然接受生活给你的馈赠吧，不管是好的还是坏的。 阅读全文

摘要： 了解同一个边界中的真正的不变量聚合的划分是需要细心设计的，聚合划分时除了根据聚合本身的定义外还应该能保证聚合内部元素的一致性，当外界通过聚合根对聚合内的元素进行修改时能使改变的元素与其他元素之间保持设定的一致性，确保概念上的不变。尽量设计小的聚合聚合设计大多数时候都会受到主观因素的影响，有的人喜欢设计大聚合（聚合包含的实体和值对象数量太多），因为觉得大聚合容易获得聚合内的其他元素，这样做虽然表面上看起来很方便，但是存在很大的弊端，大聚合在进行数据操作时不容易控制，容易造成事务失败，因此应该尽量设计小的聚合。不同聚合之间通过唯一标识来关联聚合A和聚合B之间存在关联，并且在使用聚合A时，经常需要用 阅读全文

摘要： C# VIA CLRSQLExtJs 阅读全文

摘要： 聚合 = 聚合根 + 实体 + 值对象 + 导航约束只有“聚合根”可以被其它对象“导航”到，“内部实体”只能被临时使用。”内部实体“和”值对象“在概念上只被所在的聚合根使用（本地标识）。”内部实体“和”值对象“可以导航到其它”聚合根“。设计原则 同时生存同时消亡（充分条件）。 存在不变量（充分条件）。 容易管理并发（充分条件）。 不可缺少的一部分（充分条件）。 同时加载同时保存（充分必要条件）。 阅读全文

摘要： 业务事务面向用例，一般一个请求对应一个业务事务，一个业务事务对应多个数据库事务，一个业务事务运行在一个分布式事务中，一个数据库事务最好只操作一个聚合。如何编排一个业务事务的多个数据事务呢？一、DomainService（推荐）；二、DomainEvent（推荐）；三、ApplicationService（不推荐）。如何管理分布式事务呢？一、AOP；二、AOP、三、AOP。 阅读全文

摘要： 1、认真听别人讲，别人讲的时候要跟着对方的思路走。2、不要急于否定别别人，但是不怕被别人否定。3、遇到不理解的东西，记下来，找时机继续提问。4、交流过后，要说声谢谢。 阅读全文

摘要： Command：纵向传递，跨分层，在控制器层和应用层之间传递。DomainEvent：横向传递，跨聚合，在一个DLL中。ApplicationEvent：横向传递，跨模块，在不同的DLL中。 阅读全文

摘要： 1、识别模型（内部视图）：实体、值对象、聚合、服务、工厂、仓储、领域事件。2、识别命令（外部视图）：命令、处理器、应用事件。 阅读全文

摘要： 大出着眼 小处着手前者或许比后者要容易的多，多少次提醒自己要从小处着手，又多少次因为将其置之不理而让自己置于维护的恶梦中。强化一下不扫一室，何以扫天下。不积跬步，无以至千里。 阅读全文

摘要： 环境要求安装MSMQ示例代码 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Threading.Tasks; 6 7 using System.Messaging; 8 9 namespace MSMQStudy10 {11 class Program12 {13 static void Main(string[] args)14 {15 strin... 阅读全文

摘要： 用来组织业务逻辑面向业务逻辑。细粒度。内部视图看系统。一个请求对应多个服务的多个方法。服务之间会存在依赖。职责一般包括：夸聚合协调、没办法合理放到实体中的其它领域逻辑。 阅读全文