第一次写博客有点小激动,废话不多说先上图: 01_Client:存放UI相关的项目,比如ASP.NET MVC或者相关的Web Model及View Model项目. 02_Hosting:存放与Service相关的项目,可以是Direct Service,Remoting Service,Web Service,WCF Service或者Web API Service . 03_Domain:业务逻辑相关的所有实体以及操作(根据oo的思想设计类以及类之间的关系). 04_Infrastruct

回到目录 Lind.DDD项目主要面向敏捷,快速开发,领域驱动等,对于它的分层也是能合并的合并,比之前大叔的框架分层更粗糙一些,或者说更大胆一些,在开发人员使用上,可能会感觉更方便了,更益使用了,这就是大叔开发Lind.DDD框架的目的,让一切变得更简单... Lind.DDD层 主要是公用方法,组件,规约等,如日志组件(Logger),消息组件(Messaging),IOC,AOP,缓存(Caching),异常,请求/响应,用户授权(Authorization),安全校验,领域模型(Domai

回到目录 看了传说中的弦哥对园子里.Net项目分层与文件夹结构大全(最佳架子奖,吐槽奖,阴沟翻船奖揭晓),我也来说说我的DDD架构吧,主要是看了微软NlayerApp之后,自己写的一个,以后将会应用到我的项目之中.

先说说之前几次DDD项目失败的案例,其实也不能算是失败,只是没有领会DDD的思想. 之前的DDD是建立在数据层之上的,首先是每张数据表对应一个数据实体,每个数据实体由泛型的DAO管理,DAO又被数据上下文继承以实现事务,这就构成了数据层,业务代码是写在DataContext中. 数据层:DataEntity <- DataMapper<DataEntity> <- DataContext 在这样的数据层之上构建了“貌似”DDD的领域层,首先由领域对象继承数据上下文以实现序列化和脏读

DDD这几年越来越火,资料也很多,大部分的资料都偏向于理论介绍,有给出的代码与传统MVC的三层架构差异较大,再加上大量的新概念很容易让初学者望而却步.本文从MVC架构角度来讲解如何演进到DDD架构. 从DDD的角度看MVC架构的问题 代码角度: 瘦实体模型:只起到数据类的作用,业务逻辑散落到service,可维护性越来越差: 面向数据库表编程,而非模型编程: 实体类之间的关系是复杂的网状结构,成为大泥球,牵一发而动全身,导致不敢轻易改代码: service类承接的所有的业务逻辑,越来越臃肿,很容

领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中.大部分关于此主题的著作和文章都以 Eric Evans 的书<领域驱动设计>为基础,主要从概念和设计的角度探讨领域建模和设计情况.这些著作讨论实体.值对象.服务等 DDD 的主要内容,或者谈论通用语言.界定的上下文(Bounded Context)和防护层(Anti-Corruption Layer)这些的概念. 本文旨在从实践的角度探讨领域建模和设计,涉及如何着手处理领域模型并实际地实现它.我们将着眼于技术主管和架构师在实

上一篇:<IDDD 实现领域驱动设计-由贫血导致的失忆症> 这篇博文是对<实现领域驱动设计>第一章后半部分内容的理解. Domain Experts-领域专家 这节点内容是昨天的一个讨论引发的思考. 什么是领域专家?简单来说,就是对某一业务领域精通的人,这个人可以是医生.学者.作家.艺术家等等,不管是什么职业,什么身份,只要对某一业务领域精通,都可以称之为领域专家.这样说可能会让你感到茫然,我举一个例子,比如你们软件公司要开发一套快递行业的业务系统,然后你需要到实际企业去了解业务流

一.前言 从去年已经接触领域驱动设计(Domain-Driven Design)了,当时就想自己搭建一个DDD框架,所以当时看了很多DDD方面的书,例如领域驱动模式与实战,领域驱动设计:软件核心复杂性应对之道和领域驱动设计C# 2008实现等书,由于当时只是看看而已,并没有在自己代码中进行实现,只是初步了解一些DDD分层的思想和一些基本概念,例如实体,聚合根.仓储等概念,今年有机会可以去试试面试一个架构岗位的时候,深受打击,当面试官问起是否在项目中使用过DDD思想来架构项目时,我说没有,只是了解

NServiceBus 概况 NServiceBus 概况 NServiceBus 被设计用来组合面向业务的服务,它并不是用来替代诸如 WCF 一类的RPC技术. NServiceBus 不只包含通信模块,像其他成熟的SOA和DDD项目一样,它使用了多种组合的方法和技术. 本篇文章探讨了 NServiceBus 和微软相关产品的相似点和不同点. 相比 BizTalk 更接近 WCF 当人们听到“服务总线”这个名词时,一般会描绘出如上图所示的画面,像 BizTalk 一样所有的通信都经过一个中央结

出于学习和测试的简单需要,使用 Console 来作为 EF CORE 的承载程序是最合适不过的.今天笔者就将平时的几种使用方式总结成文,以供参考,同时也是给本人一个温故知新的机会.因为没有一个完整的脉络,所以也只是想起什么写点什么,不通顺的地方还请多多谅解. 本文对象数据库默认为 VS 自带的 LocalDB 1. Normal & Simple 先介绍一种最简单的构建方式,人人都会. 新建 Console 应用程序,命名自定 安装相关Nuget 包 //Sql Server Database

这是一个由DDD群引发的随笔 在写了上一篇随笔<关于ORM的浴室沉思>后一些朋友私聊我,很多刚接触DDD的朋友会对Repository(仓储层)这东西有点疑惑,为什么要叫仓储层?是不是三层的DAL换个名字而已?毕竟大家都是对数据库的操作嘛,而且我用EF还有必要用仓储么?是不是可以省掉这一层?ABP框架的持久化究竟有什么问题? 在回答这些问题之前,我们要先了解一些模型分层的概念. DO 几乎每位程序员在刚入门时都以三层架构(3-tier architecture)为基础,界面层(User Int

NServiceBus 概况 NServiceBus 被设计用来组合面向业务的服务,它并不是用来替代诸如 WCF 一类的RPC技术. NServiceBus 不只包含通信模块,像其他成熟的SOA和DDD项目一样,它使用了多种组合的方法和技术. 本篇文章探讨了 NServiceBus 和微软相关产品的相似点和不同点. 相比 BizTalk 更接近 WCF 当人们听到“服务总线”这个名词时,一般会描绘出如上图所示的画面,像 BizTalk 一样所有的通信都经过一个中央结点.这实际上描述的是一个代理的

阅读目录 前言 六边形架构 终于开始建项目了 DDD中的3个臭皮匠 CQRS(Command Query Responsibility Segregation) 结语 一.前言 上一篇我们讲了DDD的核心概念(附上链接),并且设计了我们的上下文映射图,那么接下来就准备开始立项了,本篇文章的部分知识点可能对一部分人来说比较基础,可以选择性的阅读. 在这之前我们平常用的最多的应该就是3层架构了,这里也不展开描述了,大家都是在3层的陪伴下一路走来的~ DDD所使用的传统分层架构是松散分层,也就是上层可

在<WeText项目:一个基于.NET实现的DDD.CQRS与微服务架构的演示案例>文章中,我介绍了自己用Visual Studio 2015(C# 6.0 with .NET Framework 4.6.1)开发的DDD/CQRS/微服务架构的案例项目:WeText.文章发出后反响很好,也很感谢大家的关注.在本文中我将介绍如何在Ubuntu 14.04.4 LTS中运行WeText项目的服务端. 为跨平台而生 从一开始的设计,我就把WeText的服务端跨平台纳入了实践目标,因此,所选择的框架

最近出于工作需要,了解了一下微服务架构(Microservice Architecture,MSA).我经过两周业余时间的努力,凭着自己对微服务架构的理解,从无到有,基于.NET打造了一个演示微服务架构的应用程序案例,并结合领域驱动设计(DDD)以及命令查询职责分离(CQRS)体系结构模式,对事件驱动的微服务系统架构进行了一些实战性的探索.现将自己的思考和收获整理成文,分享给大家. 微服务架构 在介绍源代码之前,我还是想谈谈微服务架构,虽然网上有很多有关微服务架构的讨论,但我觉得在此再多说一些还

回到目录 关于Lind.DDD.Manager的培训与学习 讲解:张占岭 花名:仓储大叔 主要框架:Lind.DDD,Lind.DDD.Manager 关于Lind.DDD.Manager 由于数据模型,数据库初始化(Code.First自动升级数据库或者进行数据库版本的迁移)控制器,View视图,css,js等元素组件的一套标准的后台管理系统框架,可以直接应用到任何一个系统上,可以它将发布到Nuget上,以后安装和更新更加方便.

基于asp.net mvc + DDD 构架的开源.net cms系统. 运行截图: 特性: 跨平台 支持Windows.Linux.MacOX运行.linux运行案例:http://blog.ops.cc DDD领域驱动 使用领域驱动设计构建,通过简单的领域模型,提供了强大扩展能力. 支援多种数据库 默认使用SQLite作为数据库,同时支持Sql Server.MySQL.OLEDB(ACCESS) 支持模板引擎 内嵌一个简单的模板引擎实现,可以用html作为呈现主体.后台支持模板的安装,网络

前言 哈喽大家周五好,我们又见面了,感谢大家在这个周五读我的文章,经过了三周的时间,当然每周两篇的速度的情况下,咱们简单说了下DDD领域驱动设计的第一部分,主要包括了,<项目入门DDD架构浅析>,<领域.子领域.限界上下文>,<DDD使用意义>,<实体与值对象>,<聚合与聚合根>这五部分内容,主要的是以解释为主,举例子Code为辅的形式,总体来说还是得到一些肯定的,也是我最大的动力了. 上边这五个知识点是DDD领域驱动设计的第一部分 —— D领域

为什么要写这节文章呢?   首先主动看我这系列文章和参加活动课程的同学, 肯定是积极好学的. 所以很大概率是学过设计模式和DDD理论的. 很大概率不是走一点都不懂设计模式和DDD理论这个极端, 而是走了过度使用设计模式和DDD理论,钻了牛角尖这个极端,这个现象有个科学名词叫做“原教旨主义”   因为我会在后面团队做项目的章节里面讲到DDD理论. 所以我在这节就不过多赘述了. 就以设计模式为例吧.   设计模式起于1995年的<Design Patterns: Elements of Reusab

正如我在<程序员英语二三事(2) - 从听开始>里说的, 任何技术/工具/语言都有其适用场景和上下文环境. DDD理论同样是如此.   现在, 终于到了发挥DDD理论优势的时候啦!   一个人做一个项目不用担心代码风格不一致,不用代码看不懂别人写的代码 一个团队做项目就要考虑一致的代码风格,要保证能看得懂团队其他人的代码. 两个人一个用英语,一个用中文是很难交流的. DDD理论保证了大家使用同一种语言去交流.ABP保证了具体实施细节的一致. DDD理论相当于中文/英语,ABP相当于普通话或粤语

为什么要写这篇文章 1,在大半年前,公司开发任务比较轻松,自己不知道干什么,但是又想要学习技术,比较迷茫,后面我接触到了博客园,看了一个帖子,深有感触,我当时不知道学习什么,于是我信息给他,他居然回复我了,并且还给我建议学习的方向,以及学习的方法,我十分的感谢他. 2,在一次面试中,有人问我,你工作1年多了有没有做过自我总结,你觉得你的优势是什么,我当时吞吞吐吐的回答了,内心十分的慌张,在此补上总结. 3,学习了一段时间.Net Core了,记忆力比较差,记录下来,为以后用时做准备. 项目基础分