随笔分类 - ddd
摘要：
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对
阅读全文
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对
阅读全文
摘要：
由于博主今后一段时间可能会很忙（准备出书：《.NET框架设计—模式、配置、工具》，外加换了新工作），所以博客会很少更新； 在最近一年左右时间里，博主各种.NET技术类型的文章都写过，根据博友们的反馈觉得还不错，所以应该有整理一下目录的必要，防止随着时间的推移很多现在来说还比较新的技术文章到时候就不知名的石沉大海了；整理之后更方便大家查询，阅读，谢谢；
阅读全文
由于博主今后一段时间可能会很忙（准备出书：《.NET框架设计—模式、配置、工具》，外加换了新工作），所以博客会很少更新； 在最近一年左右时间里，博主各种.NET技术类型的文章都写过，根据博友们的反馈觉得还不错，所以应该有整理一下目录的必要，防止随着时间的推移很多现在来说还比较新的技术文章到时候就不知名的石沉大海了；整理之后更方便大家查询，阅读，谢谢；
阅读全文
摘要：DomainModel是由很多细粒度的Object组成，按照以往的教训（将Object行为、数据肢解，得到一个残缺的Object），现在我们将逻辑行为和数据绑定在一起，形成了一个丰富的领域模型，这也是面向对象设计原则之一；想了解更多关于实现面向对象的技巧请参考【《实现模式》作者：Kent Beck】一书； 但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销，试想一个OrderManager对象，如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度；根据DDD.CQRS架构，得知将DomainModel中的查询逻辑单独剥离出去，让Command端很干净的处理聚合的写逻辑，在Query端也很直接的处理查询逻辑；
阅读全文
DomainModel是由很多细粒度的Object组成，按照以往的教训（将Object行为、数据肢解，得到一个残缺的Object），现在我们将逻辑行为和数据绑定在一起，形成了一个丰富的领域模型，这也是面向对象设计原则之一；想了解更多关于实现面向对象的技巧请参考【《实现模式》作者：Kent Beck】一书； 但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销，试想一个OrderManager对象，如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度；根据DDD.CQRS架构，得知将DomainModel中的查询逻辑单独剥离出去，让Command端很干净的处理聚合的写逻辑，在Query端也很直接的处理查询逻辑；
阅读全文
摘要：本来这篇文章是“[置顶].NET领域驱动设计—实践(穿过迷雾走向光明)”一文的一部分但是由于时间关系，完整的示例并没有跟文章同步发布，说实话时间太紧，写示例的目的是想全面的且细致的阐述DDD的分析、设计各个环节的最佳实践；原本想将文章的示例做好后在发布，但是由于工作关系和一些私人原因可能有一段时间不更新博客，又不想这篇文章拖的太久，所以我总结了两点比较有价值的地方分享给大家，目的不是让大家能会使用DDD来设计系统，而是能有一个突破点来衡量DDD到底比传统三层好在哪里，因为大部分人还没有DDD的开发经验所以能体会到应该没有相关途径；
阅读全文
本来这篇文章是“[置顶].NET领域驱动设计—实践(穿过迷雾走向光明)”一文的一部分但是由于时间关系，完整的示例并没有跟文章同步发布，说实话时间太紧，写示例的目的是想全面的且细致的阐述DDD的分析、设计各个环节的最佳实践；原本想将文章的示例做好后在发布，但是由于工作关系和一些私人原因可能有一段时间不更新博客，又不想这篇文章拖的太久，所以我总结了两点比较有价值的地方分享给大家，目的不是让大家能会使用DDD来设计系统，而是能有一个突破点来衡量DDD到底比传统三层好在哪里，因为大部分人还没有DDD的开发经验所以能体会到应该没有相关途径；
阅读全文
摘要：在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。
阅读全文
在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。
阅读全文
摘要：原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则： 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则：
阅读全文
原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则： 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则：
阅读全文
摘要：最近在研究DDD颇有收获，所以整理出来跟大家分享，共同进步！ 我们在设计业务系统的时候都会存在一个非常棘手而又无法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“，尽管我们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论，但是我们似乎都没有将它们运用到真正业务系统设计、开发当中去，为什么？这样的疑问如果对有心想设计好系统的朋友来说肯定是很早就出现过，只是无法解决，因为我们目前使用的设计方法是与面向对象设计背道而驰的。
阅读全文
最近在研究DDD颇有收获，所以整理出来跟大家分享，共同进步！ 我们在设计业务系统的时候都会存在一个非常棘手而又无法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“，尽管我们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论，但是我们似乎都没有将它们运用到真正业务系统设计、开发当中去，为什么？这样的疑问如果对有心想设计好系统的朋友来说肯定是很早就出现过，只是无法解决，因为我们目前使用的设计方法是与面向对象设计背道而驰的。
阅读全文
