一年的回顾:我的领域驱动设计之路

说明:图片来自音乐期刊《年少轻狂人得意》 天气炎热,难免会有些浮躁,总结下这篇博文,希望可以给自己或他人一些向前的能量。 回头看上面是我在 2014年4月4日深

说明:图片来自音乐期刊《年少轻狂人得意

天气炎热,难免会有些浮躁,总结下这篇博文,希望可以给自己或他人一些向前的能量。

回头看

上面是我在 2014年4月4日深夜发表的一个状态,回到这个时间节点,我还记得那个画面是多么的和谐,嘴里含着布洛芬药片,一根一根的抽着烟,穿着大裤衩,抠着脚趾头,眼睛一眨不眨的欣赏这篇文章,现在想想也是醉了。

先描述一下我那时候的工作状态,和大多数软件公司一样,当时的公司是给其他企业做软件系统的,也就是企业应用开发,需求一般是对方提出,然后经过我们的“需求经理”过滤,再经过我们的项目经理“翻译”,最后传达给我们开发人员,这首先有一个时间性,有时候一个需求刚开始去实现,另一个需求就过来了,重要的是还否决了之前的需求,想想是多么的可恶,总的来说,需求是千变万化的,所以往往把我们开发人员弄的不知所措,更打消了我们的工作积极性。对于我来说,这些都不是事,忍忍也就过去了,但让我不能接受的是工作方式,或者是开发方式,公司项目是 C/S 系统,所以要做很多的 WinForms 界面,往往一个界面就是一个需求,“需求经理”会根据客户提出的需求,通过一个软件,画出一个伪的 WinForms 界面,然后我们开发人员,再根据这个伪界面还原成真界面,对于代码实现来说,有很多的重复代码,比如页面加载,公共控件点击等等,所以我们一般在实现的时候,先 Copy 一个写好的界面,然后再在这个基础上进行修改,除了修改 WinForms 界面的一些常用代码,基本上就是修改 DAL 中的 SQL 代码了,说了这么多,我想你应该可以有一个画面了。

我是一个 20 多岁的小伙子,正是青春的大好时光,对工作充满着激情,但每天去写这些重复的代码,做着重复的工作,半年、一年、甚至一年半都可以,但超过两年,我就有点受不了了,但可能有人会说:那你不能在你们公司改变这种现状吗?我只能说:地位有限,能力有限,我只能在工作之余,去改变我自己,所以那一年半的工作经历,对于我来说,并没有真正去学到什么,真正的成长都是通过自学。

上面的叙述可能有点抱怨的意思了,甚至会觉得有点夸张,但不要见怪,我的想法是希望可以对别人产生一些共鸣。

有种开发方式,对于开发人员来说,就像陷入一个沼泽,刚开始的时候,你不会感觉到什么,因为项目刚开始,业务逻辑和重复代码还不是很多,所以你会感觉到很 OK,但时间一长,你会发现,腿已经动不了了,并且身体在慢慢的下沉,因为业务逻辑在慢慢的增加,你写的重复代码也越来越多,你知道这样下去肯定不行,你最终可能会被沼泽淹没,然后你奋起挣扎,开始整理业务逻辑,减少重复代码,或者利用一些其他的工具去提高工作效率,但你发现这样会变的更糟,因为你越挣扎,你陷入沼泽就越深,于是你放弃了,“坦然”接受了这一切。

不知不觉在沼泽里,已经度过了一年半的时间,甚至都已经忘了时间的存在,但在2014年4月4日这一天,有件不同寻常的事发生了,一个人来到沼泽边,看着沼泽里奄奄一息的这个人,甚是可怜啊,于是他就拿起了一根藤条,把沼泽里的这个人给拉了出来,出了沼泽,双腿重新恢复了行走能力,像是重获新生的感觉,后来他就发现,想要脱离沼泽的唯一办法,就是“跳出”这个沼泽,使用藤条、或者绳索,而不是去奋力挣扎,这样只会陷的越来越深。

有点扯了,不知道大家有没有看懂,但确实是我想要表达的意思。

这个沼泽、沼泽里的人、这个藤条、拿藤条的人,大家可以发挥想象,然后对号入座。

强制力和自制力

下面说一下2014年4月4日之后的事,关于领域驱动设计的相关知识,我就不详细说了,因为这篇博文已经跑偏主题了,我聊一下在最近这一年,领域驱动设计的学习方式,可能也不只适用于领域驱动设计的学习,其他学习也一样适用,那就是强制力自制力

1. 强制力

强制力就是强制你去做某件事,有可能是别人强制你,或者你自己强制你自己,又或者环境强制你,但不管谁强制你,这件事都是你不得不做的,对于我来说就是,这件事就是:短消息用领域驱动设计实现。

难度越大,挑战越大,收获也就越大,何况这是一个实际在用的项目,刚开始进行的三个月,对于我来说,是最痛苦的三个月,一两个星期写不出来几行代码,有时候甚至晚上睡不着觉,整个人天天就是一种快要“濒死”的状态,这不只是身体上的,最重要的是心理上的。对于开发人员来说,最有成就感的事,就是做出一个产品,然后得到别人的认可,这就像自己的孩子一样,但那时候我的孩子实在太难养育了,甚至可以说是难产。

虽然很艰苦,但我从来没有放弃过,或者抱怨过什么,因为这是自己选择的“路”,再难也要坚持下去,然后最终完成项目,这时候,就是自己去强制自己,多写写代码,一遍不行那就多写几篇,多看看文章,一遍看不懂那就多看几遍,多写写文章,说不出来可以写出来,多虚心请教别人,自己不懂的说不定别人懂,这些都是强制力转化的学习方式。

狗急了还会跳墙呢,人要逼急了,还是可以干出超乎常理的事呢。

关于强制力,我自己觉得我们现在太缺乏了,有时候可能环境确实是这样,比如有人说英语学不好,试过各种学习方式,但总之就是学不好,然后也不知道原因是什么,我就是这样(自身原因),但试想一下,如果把你一个人丢在美国一两年,我想不用一两年,三个月的时间,你就能精通英语,为什么?因为环境强制你去学习,不会英语,就没办法交流,所以必须去学习。

最近看了一个电影《重见天日》,讲的是越战时期,一个美国空军飞行员,在执行任务的时候,被越南士兵击落了,然后在丛林中求生的经历,首先,这是一个真实的故事,而且这个飞行员是第一次执行任务,并且在出发之前,他还通过纪录片学习了丛林生存技能,也就是说,他没有丛林生活的经历,然后呢?被击落,掉到布满危机的越南丛林,他却一个人生存了下来,并最终得救。

有时候,自己不忍心狠一把,那就让别人“捅你一刀”。

2. 自制力

一个人的自制力有多强,那就看他做一件事能坚持多久,我之前要学习 CLR,然后《CLR via C#》看了三章,就丢在一边了,要学习英语,然后《人月神话》看了两章,也丢在一边了,要学习领域驱动设计,然后《领域驱动设计》和《实现领域驱动设计》挑着看了几章,现在也丢在一边了,这就是自己自制力的不足,做一件事刚开始的时候,热情高涨,但时间一长,激情慢慢就会退化,最终甚至放弃。

我觉得这个问题也很普遍,说出来也没什么丢人的地方,暴露出来问题反而是好事,可以针对问题进行改进,后来我发现这个问题之后,我试着强制自己去看书,但有时候会适得其反,因为你越是逼自己,就越讨厌自己,然后学习的效率就越不高,那怎么办呢?我后来发现一个很有效的方法,就是不要为了学习而学习,而是为了解决问题而学习,当你遇到一个问题的时候,比如你在设计领域模型的时候,是领域对象是设计成实体?还是设计成值对象呢?然后你就开始找资料,看书去查询相关的知识点,因为你是带着问题去学习的,所以很有针对性,学习的效率也就很高,当这个问题被解决的时候,关于这个问题所涉及的知识点,你也就掌握了,这比单纯的去看书要好的多,当然,如果把这个过程再写出来,那就真正的完美了。

所以,后来我基本上是这种学习方式,发现问题,查资料解决问题,然后记录下来,时间一长,累积的也就越来越多。

不积小流,无以成江海

DDD 领域驱动设计系列文章(附带简单说明):

  1. 我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践对于某件事,人生总有第一次
  2. 一缕阳光:DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)?Domain Model 沼泽开始
  3. 死去活来,而不变质:Domain Model(领域模型) 和 EntityFramework 如何正确进行对象关系映射?
  4. 拨开迷雾,找回自我:DDD 应对具体业务场景,Domain Model 到底如何设计?
  5. No zuo no die:DDD 应对具体业务场景,Domain Model 重新设计
  6. 设计窘境:来自 Repository 的一丝线索,Domain Model 再重新设计
  7. 拨乱反正:DDD 回归具体的业务场景,Domain Model 再再重新设计Domain Model 沼泽结束
  8. DDD 领域驱动设计-Value Object(值对象)如何使用 EF 进行正确映射DDD 与 EF
  9. Repository 仓储,你的归宿究竟在哪?(一)-仓储的概念Repository 困惑开始
  10. Repository 仓储,你的归宿究竟在哪?(二)-这样的应用层代码,你能接受吗?
  11. Repository 仓储,你的归宿究竟在哪?(三)-SELECT 某某某。。。Repository 困惑结束
  12. DDD 领域驱动设计-看我如何应对业务需求变化,愚蠢的应对?真正去思考的四篇博文开始
  13. DDD 领域驱动设计-看我如何应对业务需求变化,领域模型调整?
  14. DDD 领域驱动设计-三个问题思考实体和值对象
  15. DDD 领域驱动设计-三个问题思考实体和值对象(续)真正去思考的四篇博文结束
  16. DDD 领域驱动设计-“臆想”中的实体和值对象瞎扯的一篇博文
  17. IDDD 实现领域驱动设计-由贫血导致的失忆症边看书,边思考,边记录 Ⅰ
  18. IDDD 实现领域驱动设计-一个简单业务用例的回顾和理解边看书,边思考,边记录 Ⅱ
  19. IDDD 实现领域驱动设计-理解领域和子域边看书,边思考,边记录 Ⅲ
  20. IDDD 实现领域驱动设计-理解限界上下文边看书,边思考,边记录 Ⅳ
  21. IDDD 实现领域驱动设计-上下文映射图及其相关概念边看书,边思考,边记录 Ⅴ
  22. IDDD 实现领域驱动设计-架构之经典分层DDD 架构设计 I
  23. IDDD 实现领域驱动设计-SOA、REST 和六边形架构DDD 架构设计 II
  24. IDDD 实现领域驱动设计-CQRS(命令查询职责分离)和 EDA(事件驱动架构)DDD 架构设计 III
  25. IDDD 实现领域驱动设计-一个简单的 CQRS 示例看起来很简单,但其实并不简单
  26. DDD 主题交流会总结及计划牛人很多
  27. 在路上......
您可能有感兴趣的文章
DDD领域驱动设计理解