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

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

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

回头看

上面是我在 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. 在路上......