领域驱动的一些思想

首先我们从字面上理解一下,领域理解为业务,驱动理解为驱导,也就是用业务去驱导项目开发,确立业务在项目的领导地位。

在传统的开发流程中。

前三个步骤分别是

1.需求分析 :描述业务。

2.概要设计 :设计软件结构。

3.详细设计:对软件结构的详细描述(使用的算法,数据表,流程图等)

完成这三个步骤以后,通常会进入编码阶段,在编码阶段整个系统开发会自下而上。也就是说先设计好数据库表,建立数据层,通过数据层对外提供数据接口。然后开发业务逻辑层,业务逻辑层依赖仓储。最后是表现层,表现层依赖业务逻辑层和数据层。

在这种自下而上的模式中。业务逻辑层依赖数据层的数据接口。你可以做一个不合理的假设,这个系统现在只有两个开发人员他们互不认识,一个开发数据层,一个开发业务逻辑层。在没有沟通的情况下,业务逻辑层并非主导,因为数据层决定我给你什么接口,不给你什么接口,我要改接口你也得跟着改。这种开发模式显然并不合适日益庞大的业务需求。在领域驱动的思想中,所有的工作中心都必须围绕业务层,必需让业务层做主导。前面那个假设就变成了业务层的开发人员制定数据接口,数据层以来这个数据接口,并实现它。这种情况下,业务层完全变成主导,要或者不要,改或者不改。

对比这两者。


传统模式


领域驱动


工作重心


数据库和仓储层


业务逻辑层

时间: 2024-12-17 08:53:14

领域驱动的一些思想的相关文章

领域驱动设计的面向服务架构

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列

EntityFramework之领域驱动设计实践

EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动设计实践 (五):聚合 EntityFramewor

Re:从零开始的领域驱动设计

领域驱动的火爆程度不用我赘述,但是即便其如此得耳熟能详,但大多数人对其的认识,还只是停留在知道它的缩写是DDD,知道它是一种软件思想,或者知道它和微服务有千丝万缕的关系.Eric Evans对DDD的诠释是那么地惜字如金,而我所认识的领域驱动设计的专家又都是行业中的资深前辈,他们擅长于对软件设计进行高屋建瓴的论述,如果没有丰富的互联网从业经验,是不能从他们的分享中获取太多的营养的,可以用曲高和寡来形容.1000个互联网从业者,100个懂微服务,10个人懂领域驱动设计. 可能有很多和我一样的读者,

领域驱动设计案例之业务实现1

业务上主要实现产品的创建,客户的创建.下订单的业务,这里主要演示领域驱动设计的思想与一些最佳实践如何体现到领域的实现中,代码中的一些 Bug或瑕疵不用太过理会. 在DDD.Doman项目中实现相应的聚合根.实体与值对象. 这篇文章主要实现客户的创建,因为通过Model-First已经建立了领域模型,所以我们建立分部类来实现领域对象的业务逻辑部分. public partial class Customer:AggreateRoot { private IRepository<Customer>

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店

一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网

关于领域驱动设计与GIT的优势的个人理解

注:本文系作者原创,但可随意转载. 本文纯属个人观点,才疏学浅,不当之处,敬请斧正. 一.领域驱动设计 经常看到大家在讨论这个问题,百度一下也能看到很多相关博客.本身我并没有阅读过相关的书籍,只是百度过一些概念之类的,可能并没有真正地理解这个概念. 首先,领域驱动设计的核心是模型,在于建立一个领域模型.对于这个概念还是深表认同.我认为领域驱动设计的目的,本身即是为了便于理解,加快开发.领域模型即是对客观事实进行建模,而不是基于抽象,那么所建立的模型通俗易读,阅读代码的人一看就知道是什么意思. 举

(转)EntityFramework之领域驱动设计实践

EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动设计实践 (五):聚合 EntityFramewor

我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践

写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课.第一次骑自行车.第一次懂事.第一次和喜

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型: