软件架构的终极目标：最大化程序员的生产力，最小化运营的总成本。
前奏
目前我在看两本书《领域驱动设计精粹》和《实现领域驱动设计》，前一本比较薄，不到150页，后一本就非常厚实了，有500多页，那么读起来可能就会显得有点心理障碍，但如果要想更多了解DDD，还是要以第二本为主，第一本可以作为概要性阅读。
领域驱动设计，类似**驱动，我们也接触过不少，比如测试驱动，敏捷驱动等等。领域驱动设计，这六个字或者在前面再加上业务两字，业务领域驱动设计，最终的目标都是为了设计服务的，那么设计是设计的什么，肯定是应用程序系统架构，那么应用程序系统的架构有什么样的需求呢。
架构有两种需求：功能性需求和非功能性需求。
功能性需求就是我们在使用一个系统的时候所接触到的，所用到的诸多功能，比如发布一个商品，展示一个统计报表，做权限的管理和控制等，代表的是一个应用程序系统架构能做什么。
非功能性需求是我们的这个应用程序系统架构是否做到了可监控、可扩展、是否高可用、高性能等，代表的是一个应用程序在运行时的质量。非功能性需求中，还有一个非常重要的点就是：快速安全的交付软件。
那么我们就随着如何快速安全的交付软件说起。DDD重要的指导思想之一是将业务人员和研发人员拉在了一起。敏捷开发的周期内，无论需求梳理会、回顾会还是计划会都没有业务人员的影子，总是研发和产品在交流。
在业务建模之后技术人员来考虑如何快速且安全的交付软件产品。
随着软件架构的逐渐成熟，在我们已经认识的AKF立方体中，在X轴的服务器水平复制，和Z轴的数据分库分表，这两个方向上我们的技术都已经相对成熟，使得我们在抗住大访问量方面已经不再被动。
但唯独在Y轴这个方向上，业务对应服务的拆分，和应用程序被要求快速的交付，我们始终没有太好的解决方法。
而DDD正是致力于在这个方向上为软件开发人员做指导的，利用DDD如何快速的交付软件。
因为这是我的DDD学习笔记第一篇文章，就花费了上面的篇幅来做个浅显的对DDD的理解引入描述。接下来我主要谈一谈DDD学习中的战术设计中的一种：运用领域事件进行战术设计。
事件产生于核心域
领域驱动设计中涵盖的内容基本是两大内容，战略设计和战术设计，领域事件是属于战术设计的范畴内的。
那么是先有的事件还是现有的领域呢，我个人认为在动作发生关系上，是先有的事件，已经存在发生过去一段时间了。
比如我们在利用事件驱动开发的时候，常常借助的中间件就有很多，ActiveMQ、RocketMQ等等。后来我们有了领域的概念认知，那么就开始使用领域的思维来去思考事件：领域事件。
如今借助了领域的概念，我们相当于换了一种思考方式，好比 “横看成岭侧成峰，远近高低各不同”，最终都是山，但 “成峰” 的时候可能更能便于我们理解和认知我们的业务关系，我们就使用 “成峰” 的角度去思考。
假如在一个月前我还没有接触领域事件，上面也说了我们一直在用消息机制（消息中间件）解决问题。那么现在我开始学了领域事件给我带来什么变化或者新的认知呢。
首先，我觉得是统一了语言：领域事件，好比古人一手取了一根木棍，另一只手又取了一根木棍，两只木棍来回摩擦，生出火来。这件事情很伟大，但描述起来就比较费劲，后面就有人总结说了叫做：钻木取火，这样传播起来就方便了，大家一听到钻木取火就知道是什么意思。
领域事件也是如此，因为之前毕竟你已经有了领域上下文的知识。
总结
没有DDD，我们业务中也是已经存在了边界，关系，交互，有了DDD之后，我们是依靠或者借助其帮我们梳理这些业务关系，划清业务边界，形成独立性、自治性、弱耦合的系统。
当我们阅读相关DDD书籍里面描述的对象和实践时候使用的对象，都没有变，那些对象都是一直存在的。但是，我个人认为DDD是一种思考业务问题、架构问题的方式，学习了DDD知识以后就可以采用“DDD的思维方式”去理解和处理那些我们在工作中已经存在的对象。
但也要明白，它绝不是解决一切问题的银弹。
DDD就是一种工具，好比是一把剑，也可能有另外一种工具XXD，好比是一把刀，至于是剑厉害，还是刀厉害，主要看你使用的熟练程度。
参考书籍《领域驱动设计精粹》和《实现领域驱动设计》和《架构整洁之道》
