[转]从三层架构迈向领域驱动设计 — 关于领域设计中描述相对简要及明了的一篇文章
摘要：本文读者基本要求：从事信息管理系统开发，略懂GOF设计模式及SOLID设计原则，对三层面向过程机械编码厌倦，并且不知道出路在何方，如果还掌握代码坏味和重构手法，那是极好的。 1. 三层架构 理论介绍-->实际经验-->总结反思 1.1 简单介绍三层架构 严格分层架构模式的特点是上层只能访问相邻的下层
阅读全文
posted @ 2016-11-23 16:47
随笔分类 - DDD
[转] .NET领域驱动设计—看DDD是如何运用设计模式颠覆传统架构
摘要：阅读目录： 1.开篇介绍 2.简单了解缘由（本文的前期事宜） 3.DomainModel扩展性（运用设计模式设计模型变化点） 3.1.模型扩展性 3.2.设计模式的使用（苦心专研的设计模式、设计思想可以随意使用了） 3.3.部分类的使用（封装内部对象） 3.4.高强度的OO设计（面向特定领域的高度抽
阅读全文
posted @ 2014-01-15 12:06
[转] .NET领域驱动设计—实践(穿过迷雾走向光明)
摘要：阅读目录开篇介绍1.1示例介绍 (OnlineExamination在线考试系统介绍)1.2分析、建模 (对真实业务进行分析、模型化)1.2.1 用例分析 (提取系统的所有功能需求)1.3系统设计、建模 (技术化业务模型)1.3.1 枚举类型的使用 (别让枚举类型成为数值型对象)1.3.2 基础数据、业务数据 (显示实体和隐式过程)1.3.3 模型在数据库中的主外键关联问题 (面向对象模型与关系模型的天然抗阻)1.3.4 角色、类型 (区分类型与面向对象概念)1.3.5 名词、动词、隐、显、抽象、具体 模型创建技巧 (面向对象分析技巧)1.3.6 永远都不要去假设你的模型 (28原则)1.4重
阅读全文
posted @ 2014-01-15 12:05
[转] .NET领域驱动设计—初尝(原则、工具、过程、框架)
摘要：阅读目录：1.原则1.1.精简聚合1.2.分离用例与接口功能（设计模式的用武之地）2.工具、框架、组件3.过程1】原则原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则：【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】
阅读全文
posted @ 2014-01-15 12:04
[转] .NET领域驱动设计—初尝(疑问、模式、原则、工具、过程、框架、实践)
摘要：阅读目录：1.1.疑问1.1.1.UML何用1.1.2.领域建模1.2.模式1.3.原则1.5.过程1.6.框架1.7.项目演示最近在研究DDD颇有收获，所以整理出来跟大家分享，共同进步！我们在设计业务系统的时候都会存在一个非常棘手而又无法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“，尽管我们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论，但是我们似乎都没有将它们运用到真正业务系统设计、开发当中去，为什么？这样的疑问如果对有心想设计好系统的朋友来说肯定是很早就出现过，只是无法解决，因为我们目前使用的设计方法是与面向对象设计背道而驰的。漫长的数据库驱动开发历史
阅读全文
posted @ 2014-01-15 12:03
[转] DDD领域驱动设计（三） 之 理论知识收集汇总
摘要：最近一直在学习领域驱动设计（DDD）的理论知识，从网上搜集了一些个人认为比较有价值的东西，贴出来和大家分享一下：我一直觉得不要盲目相信权威，比如不能一谈起领域驱动设计，就一定认为国外的那个Eric Evans写的那本书中的一些概念就一定是正确的，认为领域驱动设计就一定是聚合，聚合根，实体，值对象等概念。我们要有自己的思想，要有自己判断真正的领域模型该是什么样子的勇气和追求。"领域驱动设计" = “问题域模型驱动领域建模” + “领域建模驱动软件实现”问题域建模的过程就是业务领域分析的过程，对于企业而言就是业务架构的分析和建立过程，这里不包含任何OO的设计成分，主要从组织、流
阅读全文
posted @ 2014-01-10 16:43
[0] DDD领域驱动设计（三） 之 聚合（根）、实体、值对象
摘要：1.聚合根、实体、值对象的区别？从标识的角度：聚合根具有全局的唯一标识，而实体只有在聚合内部有唯一的本地标识，值对象没有唯一标识，不存在这个值对象或那个值对象的说法；从是否只读的角度：聚合根除了唯一标识外，其他所有状态信息都理论上可变；实体是可变的；值对象是只读的；从生命周期的角度：聚合根有独立的生命周期，实体的生命周期从属于其所属的聚合，实体完全由其所属的聚合根负责管理维护；值对象无生命周期可言，因为只是一个值；2.聚合根、实体、值对象对象之间如何建立关联？聚合根到聚合根：通过ID关联；聚合根到其内部的实体，直接对象引用；聚合根到值对象，直接对象引用；实体对其他对象的引用规则：1）能引用其所
阅读全文
posted @ 2014-01-10 15:52
[0] DDD领域驱动设计（二） 之 值对象
摘要：DDD中实体对象与值对象的解释比较抽象。主要根据持续性与 ID 识别来区分。 ID并非某一对象的直观自然属性，而是在分析建模之 后，赋给模型中的实体类，来达到跟踪，区别，存储目的的一个特值。结合项目实践及 DDD一书中的理论，感觉应该从以下几方面分析：1.主从：某一概念是主动还是从属性的，如果是从属性的，且这种 从属性的生命周期严格依赖于某实体，如可以考虑成为值对象的候 选。 2. 复用：某一概念是否可以被复用，共享，复制。象对应领域属性， 规格，策略，规则的类，虽然对其他实体类的依赖性不是很强，可以 独立存在。可以被不同的实体对象（不是指类）共享，复制，复用。 如人的地址属性，画笔的颜色字体
阅读全文
posted @ 2014-01-10 15:49
[转] DDD领域驱动设计框架分享
摘要：从去年10月份开始，学了几个月的领域驱动设计（Domain Driven Design，简称DDD）。主要是学习领域驱动设计之父Eric Evans的名著：《Domain-driven design：领域驱动设计:软件核心复杂性应对之道》，以及另外一本Martin Flower的《企业应用架构模式》，学习到了不少关于如何组织业务逻辑方面的知识。另外，在这个过程中也接触到了一些开源的架构和一些很好的思想。如：命令查询职责分离（Command Query Responsibility Segregation，简称CQRS），事件驱动架构（Event Driven Architecture，简称ED
阅读全文
posted @ 2014-01-10 15:28
