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

注:本文系作者原创,但可随意转载。

  本文纯属个人观点,才疏学浅,不当之处,敬请斧正。

一、领域驱动设计

  经常看到大家在讨论这个问题,百度一下也能看到很多相关博客。本身我并没有阅读过相关的书籍,只是百度过一些概念之类的,可能并没有真正地理解这个概念。

  首先,领域驱动设计的核心是模型,在于建立一个领域模型。对于这个概念还是深表认同。我认为领域驱动设计的目的,本身即是为了便于理解,加快开发。领域模型即是对客观事实进行建模,而不是基于抽象,那么所建立的模型通俗易读,阅读代码的人一看就知道是什么意思。

  举个例子:

   假设现在要做一个公司的内部人力资源管理系统,那么我们对系统进行简单地建模。

 1 public class Company
 2 {
 3     public int CompanyId {get;set;}
 4     public string CompanyName {get;set;}
 5     public List<Department> Departments {get;set;}
 6     public string Address {get;set;}
 7     public string Contact {get;set;}
 8     public string Phone {get;set;}
 9     ...
10 }

Company类

 1 public class Department
 2 {
 3     public int DepartmentId {get;set;}
 4     public string DepartmentName {get;set;}
 5     public int CompanyId {get;set;}
 6     public virtual Company Company {get;set;}
 7     public int ManagerId {get;set;}
 8     public virtual Employee Manager {get;set;}
 9     public List<Employee> Employees {get;set;}
10     ...
11 }

Department类

1 public class Employee
2 {
3     public int EmployeeId {get;set;}
4     public string EmployeeName {get;set;}
5     public int Age {get;set;}
6     public string Gender {get;set;}
7     ....
8 }

Employee类

  很容易可以得出这样三个类,只需要把他们所拥有的属性按照客观事实写进去就可以,读代码的人也很容易GET到写代码的人的点。实际上建模也即是对数据库的设计,结合EF的CODE FIRST功能,可以直接在MSSQL中建立三张对应这三个类的表。在系统的使用过程中,大部分也是对表中数据简单的增删查改,可以直接通过领域模型来操作数据。这样大大提高了开发速度。

  但我认为像这样建模仅适用于对真实世界进行建模,业务不是十分复杂的情形。如果我们提取出了领域模型,但是在实际使用的时候总是需要在领域模型,DTO, ViewModel之间转换来转换去,那么程序的结构实际上已经变成了事务脚本的模式,模型间的转换反倒加重了阅读和写代码的负担。

  再举个例子:

  假设现在做一个类似传奇的游戏,游戏里有装备道具,那么我们设计一个Item表,那这个表我个人理解应该是类似这样的。

  ItemId, ItemType, Attack, DaoShu, MoFa, Defense, AttackRate, RequiredLevel, RequiredAttack, RequiredDaoShu, RequiredMofa, SellingPrice ....

  道具根据ItemType判断到底是武器还是盔甲,所有的装备都可以根据这一张表在游戏世界里创造出来。所以战士的 重盔甲 一类的盔甲不但加防御,还可以加攻击。

  但如果按领域驱动设计的思想来设计的话,那么可能武器会有个武器类,盔甲有个盔甲类, 武器类中的字段里不应该有防御, 盔甲类的字段里也不应该有攻击。这是这样便不方便扩展了,游戏版本的更新带来新的玩儿法是很常见的,可能以后装备再加个附魔属性之类的。基于抽象的数据库设计更适合这种场合。

  

二、GIT的优势

  其实也是恰好前一阵面试被问到这个问题。GIT, SVN, TFS在不同的公司的实际生产中都用过, SVN是实习的时候用已经记不清了,只是在自己电脑上单机管理文件用。但我还是把他们写到简历里,纯属凑字数。

  当时被问到的时候说我代码管理工具都用过啊,我多嘴说了一句我觉的GIT更好用,然后紧接着就被问到GIT相比TFS的优势在哪。我思考了一分钟没想上来,因为我觉得我得说个具体的事例来,如果说性能好,速度快,肯定会被问性能哪里好,速度怎么快,而且本身这类宽泛的回答也没有实际意义。然后我就说这个问题先放一放,可能过了几分钟十几分钟的样子,在回答其他问题的时候写心情没那么紧张了就顺便想了下这个问题,还真被我想出来了一个具体的细节,然后回答了他,面试官顿时觉得眼前一亮,不然我看已经准备叫我走人了,没什么想说的了。。。

  其实面试的时候我边答,他拿个电脑边在那百度。。。我回去后也试着百度了一下,百度出来的答案无非也是性能好之类的泛泛的答案。

  我个人觉得 GIT相比TFS最重要的优势在于并行工作。

  TFS在同一个项目中,同一个文件只能由一人签出,A签出了,B就不能修改。假如A负责开发在线支付接口,B负责开发用户反馈,二者在业务上没有任何关系,但可能都要修改一个DataBase的配置文件。那么A完成工作前, B都没办法修改这个文件来进行调试。

  在GIT下,则A和B同时可以修改同一文件,只是改完以后需要二人合作进行一下合并操作。使得并行工作成为可能。

  

  

时间: 2024-07-30 19:28:42

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

DDD学习笔录——领域驱动设计的常见误区(即错误的理解)

可以将DDD看成一种开发思想体系:它促成了一种新的以领域为中心的思维方式. 它是一种学习过程,而非最终目标,这就是DDD的最大优势. 任何团队都可以编写一个软件来满足一组用例的需求,但那些将时间和精力花在其正在处理的问题域中的团队则能够持续演化产品以满足新的业务用例. DDD本身并非一种严格的方法论,而是必须与一些迭代式软件项目方法论结合使用以构建并演化一个有用的模型. 由此可见下面的这些理解,存在很大的误区: 1.战术模式是DDD的关键 这明显不对,DDD并不是一种面向对象的设计,也不是一种以

领域驱动设计系列(转)

曾经参与过系统维护或是在现有系统中进行迭代开发的软件工程师们,你们是否有过这样的痛苦经历:当需要修改一个Bug的时候,面对一个类中成百上千行的代码,没有注释,千奇百怪的方法和变量名字,层层嵌套的方法调用,混乱不堪的结构,不要说准确找到Bug所在的位置,就是要清晰知道一段代码究竟是做了什么也非常困难.最终,改对了一个Bug,却多冒出N个新Bug.同样的情况,当你拿到一份新的需求,需要在现有系统中添加功能的时候,面对一行行完全过程式的代码,需要使用一个功能时,不知道是应该自己编写,还是应该寻找是否已

领域驱动设计系列(3)有选择性的使用领域驱动设计

本系列的第一篇博文抛砖引玉,大谈领域驱动设计的优势,这里笔者还是希望以客观的态度,谈谈领域驱动设计的缺点及其不适合使用的场景,以让读者可以有选择性的使用领域驱动设计. 我们知道,没有最好,只有最合适,设计也是一样.因此,所谓设计,就是以你和你的团队的知识.经验和智慧,全面充分的考虑各种内外因素后,在你们的设计方案中作出合理的选择的过程.而这些影响你们选择的因素主要有: 技术框架的特征和约束(如果你的项目决定使用C语言进行开发,那么首先在设计方法上,就需要使用面向过程而非面向对象的设计方法). 时

领域驱动设计系列文章(3)——有选择性的使用领域驱动设计

本系列的第一篇博文抛砖引玉,大谈领域驱动设计的优势,这里笔者还是希望以客观的态度,谈谈领域驱动设计的缺点及其不适合使用的场景,以让读者可以有选择性的使用领域驱动设计. 我们知道,没有最好,只有最合适,设计也是一样.因此,所谓设计,就是以你和你的团队的知识.经验和智慧,全面充分的考虑各种内外因素后,在你们的设计方案中作出合理的选择的过程.而这些影响你们选择的因素主要有: 技术框架的特征和约束(如果你的项目决定使用C语言进行开发,那么首先在设计方法上,就需要使用面向过程而非面向对象的设计方法). 时

领域驱动设计案例之领域层框架搭建

根据前面对领域驱动设计概念以及一些最佳实践的理解,领域模型是系统最核心的部分,我们还是采用前面销售订单的例子,这个案例系统的核心构建就从领域层开始.领域层框架搭建主要完成两个任务: 1.领域模型的建立,聚合与聚合根的确定,关系的确定. 2.建立支持DDD理论的领域层接口. 这里先上代码图,再详细讲每个部分的主要功能: 1.Model中主要确定了领域对象,聚合与聚合根,关联关系等,我们这里采用的是EF 的Model First建模,你也可以采取Code First.如下图: 2.Aggreate中

.NET领域驱动设计—看DDD是如何运用设计模式颠覆传统架构

阅读目录: 1.开篇介绍 2.简单了解缘由(本文的前期事宜) 3.DomainModel扩展性(运用设计模式设计模型变化点) 3.1.模型扩展性 3.2.设计模式的使用(苦心专研的设计模式.设计思想可以随意使用了) 3.3.部分类的使用(封装内部对象) 3.4.高强度的OO设计(面向特定领域的高度抽象设计形成特定领域框架) 4.DomainModel业务逻辑规则配置(将扩展点分离后使用适当的配置将规则IOC进去) 5.DDD简单总结(DDD是什么?它是"战术") 1]开篇介绍 这篇文章

领域驱动设计 ——一种将概念模型化的方式

原文发布于:http://www.gufeng.tech/ 1.引子 2004年Eric Evans 发表了一本书:<Domain-Driven Design: Tackling Complexity in the Heart of Software>(中文名:<领域驱动设计:软件核心复杂性应对之道>),在这本书中作者提出了领域驱动设计(DDD)的概念,到现在已经10多年的时间了. 1.1 面向对象与面向对象语言 面向对象思想已经存在相当长的历史了(相对于软件的历史),我而们使用的

DDD领域驱动设计仓储Repository

DDD领域驱动设计初探(二):仓储Repository(上) 前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇

领域驱动设计学习笔记(一 事件总线)

何为领域驱动设计? 2004年著名建模专家Eric Evans发表了他最具影响力的书籍:<Domain-Driven Design: Tackling Complexity in the Heart of Software>(中文译名:领域驱动设计:软件核心复杂性应对之道),书中提出了领域驱动设计(简称 DDD)的概念. 领域驱动设计事实上是针对OOAD的一个扩展和延伸,DDD基于面向对象分析与设计技术,对技术架构进行了分层规划,同时对每个类进行了策略和类型的划分. 领域模型是领域驱动的核心.