说明：图片来自音乐期刊《年少轻狂人得意》
天气炎热，难免会有些浮躁，总结下这篇博文，希望可以给自己或他人一些向前的能量。
回头看
上面是我在 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 领域驱动设计系列文章（附带简单说明）：
- 我的“第一次”，就这样没了：DDD（领域驱动设计）理论结合实践（对于某件事，人生总有第一次）
- 一缕阳光：DDD（领域驱动设计）应对具体业务场景，如何聚焦 Domain Model（领域模型）？（Domain Model 沼泽开始）
- 死去活来，而不变质：Domain Model（领域模型） 和 EntityFramework 如何正确进行对象关系映射？
- 拨开迷雾，找回自我：DDD 应对具体业务场景，Domain Model 到底如何设计？
- No zuo no die：DDD 应对具体业务场景，Domain Model 重新设计
- 设计窘境：来自 Repository 的一丝线索，Domain Model 再重新设计
- 拨乱反正：DDD 回归具体的业务场景，Domain Model 再再重新设计（Domain Model 沼泽结束）
- DDD 领域驱动设计－Value Object（值对象）如何使用 EF 进行正确映射（DDD 与 EF）
- Repository 仓储，你的归宿究竟在哪？（一）－仓储的概念（Repository 困惑开始）
- Repository 仓储，你的归宿究竟在哪？（二）－这样的应用层代码，你能接受吗？
- Repository 仓储，你的归宿究竟在哪？（三）－SELECT 某某某。。。（Repository 困惑结束）
- DDD 领域驱动设计－看我如何应对业务需求变化，愚蠢的应对？（真正去思考的四篇博文开始）
- DDD 领域驱动设计－看我如何应对业务需求变化，领域模型调整？
- DDD 领域驱动设计－三个问题思考实体和值对象
- DDD 领域驱动设计－三个问题思考实体和值对象（续）（真正去思考的四篇博文结束）
- DDD 领域驱动设计－“臆想”中的实体和值对象（瞎扯的一篇博文）
- IDDD 实现领域驱动设计－由贫血导致的失忆症（边看书，边思考，边记录 Ⅰ）
- IDDD 实现领域驱动设计－一个简单业务用例的回顾和理解（边看书，边思考，边记录 Ⅱ）
- IDDD 实现领域驱动设计－理解领域和子域（边看书，边思考，边记录 Ⅲ）
- IDDD 实现领域驱动设计－理解限界上下文（边看书，边思考，边记录 Ⅳ）
- IDDD 实现领域驱动设计－上下文映射图及其相关概念（边看书，边思考，边记录 Ⅴ）
- IDDD 实现领域驱动设计－架构之经典分层（DDD 架构设计 I）
- IDDD 实现领域驱动设计－SOA、REST 和六边形架构（DDD 架构设计 II）
- IDDD 实现领域驱动设计－CQRS（命令查询职责分离）和 EDA（事件驱动架构）（DDD 架构设计 III）
- IDDD 实现领域驱动设计－一个简单的 CQRS 示例（看起来很简单，但其实并不简单）
- DDD 主题交流会总结及计划（牛人很多）
- 在路上......