前言 领域驱动设计是一个开放的设计方法体系,目的是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题,本文将介绍领域驱动的相关概念. 一.软件复杂度的根源 1.业务复杂度(软件的规模) 软件的需求决定了系统的规模.当需求呈现线性增长的趋势时,为了实现这些功能,软件规模也会以近似的速度增长.由于需求不可能做到完全独立,导致出现相互影响相互依赖的关系,修改一处就会牵一发而动全身.就好似城市的一条道路因为施工需要临时关闭,此路不通,通行的车辆只能改道绕行,这又导致了其他原本已经饱…

道可道,非常道. 名可名,非常名. 无名天地之始,有名万物之母. ---老子 关于标题 好久没写东西了,动笔的动机是看完了一本书,想写点总结性的东西,一是为了回顾一下梳理知识点,二是为了日后遗忘时能有个简短的文章帮助自己快速回忆. 标题看着像上学时写的作文题目,原本想找个高大上的题目好拉拉人气,但关于领域驱动设计我也才处在守破离的守得级别,还是老老实实用个规矩的标题吧. 核心内容 作者在书中反复强调领域通用语言(Ubiquitous Language)的重要性,依据领域通用语言剥离出核心领域(C…

摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.csdn.net/bluishglc/article/details/6681253转载请注明出处! 目录 1.      架构概述2.      架构详解        2.1.   …

摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.csdn.net/bluishglc/article/details/6681253 转载请注明出处! 目录 1.      架构概述2.      架构详解        2.1.  …

一.为什么要分层 分层架构是所有架构的鼻祖,分层的作用就是隔离,不过,我们有时候有个误解,就是把层和程序集对应起来,就比如简单三层架构中,在你的解决方案中,一般会有三个程序集项目:XXUI.dll.XXBLL.dll 和 XXDAL.dll,然后把这三个程序集看成一个层,这没什么不可以,但当项目复杂的时候,如果还按照这种方式的话,你的程序集中的文件夹会越来越多,程序集也会越来越大.当你的视野跳出这个程序集的概念后,你会发现,层不只是和程序集对应,也和解决方案文件夹,或者是整个解决方案对应,一个层…

写在前面 阅读目录: 问题根源是什么? <领域驱动设计-软件核心复杂性应对之道>分层概念 Repository(仓储)职责所在? Domain Model(领域模型)重新设计 Domain Service(领域服务)的加入 MessageManager.Domain.Tests 的加入 Application Layer(应用层)的协调? Unit Of Work(工作单元)工作范围及实现? 版本发布 后记 在上一篇<我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践>…

DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)? 阅读目录: 问题根源是什么? <领域驱动设计-软件核心复杂性应对之道>分层概念 Repository(仓储)职责所在? Domain Model(领域模型)重新设计 Domain Service(领域服务)的加入 MessageManager.Domain.Tests 的加入 Application Layer(应用层)的协调? Unit Of Work(工作单元)工作范围及实现? 版本发布 后记 在上一…

最近新接了一个业务系统——社区服务系统,为了快速熟悉和梳理老系统的业务逻辑和代码,同时对老系统代码做一些优化,于是打算花上一个月时间不间断地对老系统服务进行重构.同时,考虑到社区业务的复杂性,想起了之前做用户系统时尝试过的领域驱动建模(简称DDD,英文全称为:Domain Driven Design),思量之下,觉得DDD非常适合这种复杂业务逻辑的系统.毫不迟疑,开搞! 之前在做用户系统时,也尝试使用DDD进行业务建模,但迫于项目工期压力,没有进行深入的学习和建模,最后效果不是很理想,为了避免重…

博客园首页是需要分享干货的地方,今天早上写的<HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍>内容下架了,所以我就按照相关规定,只分享干货,我把之前写完的内容整理发布上来.这次主要分享一下在架构设计过程中涉及的基础知识,主要是涵盖系统架构方法.架构模式及设计模式,便于大家在后续一起探讨HRMS系统的SaaS模式的架构设计. 一.设计模式 大家或多或少的都接触并在实际的开发过程中无形中可能都使用了某种设计模式,可能我们并不知道具体的模式叫什么名字,现在讲设计模式的书.案例分享都…

写在前面 阅读目录: 具体业务场景 业务需求变化 "愚蠢"的应对 消息列表实现 消息详情页实现 消息发送.回复.销毁等实现 回到原点的一些思考 业务需求变化,领域模型变化了吗? 对象读取的额外思考 写在最后 领域驱动设计的核心-Domain Model(领域模型),这个大家都知道,可是,上次关于领域模型的设计分享,要追溯到两个月之前了,这中间搞了一些有的没有的东西,比如纠结于仓储等,说这些东西不重要,其实也蛮重要的,因为它是一个完整应用程序所必须要考虑的东西(Demo 除外),但是相对…