周六参加了ThoughtWorks组织的DDD领域驱动设计的分享和Workshop，算是对DDD有了第一次学习和体会。
在参加分享之前，对于DDD只是听过几次这个名字而已，其背后的具体细节完全不了解。由于自己知道一些TDD测试驱动开发的知识，所以本能的认为DDD也是一种分析需求最终得到好代码的手段。也就是说我所想象的DDD其目的是侧重于得到好代码。不过听了演讲者的分享后，我觉得之前的认知是错误的。DDD的侧重点似乎更偏向于业务层面的梳理，它强调的是首先从业务架构的视角入手来分析用户的需求，并以这个活动为中心，连接其他两个重要的设计活动 -- 系统架构设计和技术架构设计。演讲者举了一些例子，比如曾经他们参与过一个IBM的项目，当时每次与客户沟通时，都是通过一个数据库ER关系图来进行沟通。结果在项目进行了N年之后宣告失败，原因是不满足客户的业务需求。如果从这个例子来理解DDD的目标，我觉得可以这样看，当软件系统的实现者拿到客户的需求后，首先就开始考虑ER关系图、spring-struts-hibernate、MVC、微服务这种技术手段的话，其方式是在让业务来适配技术，而且开发与客户沟通、开发人员内部自己沟通时，也是以技术作为承载各自意图传递的工具的话，就容易出现需求沟通上的困难，大家很容易对需求的理解造成偏差，最终导致在代码实现上出现错误。而这正是DDD认为的问题所在，DDD认为这个应该反过来，即应该技术来适配业务，业务是核心，是出发点。
具体的办法上，DDD的手段是通过分析用户的需求，来建立业务的模型。业务模型是对用户业务的一种描述，这里不涉及到任何技术上的元素，在构建这个模型过程中，我们不会考虑要选什么编程语言，要用什么数据库，我们的数据库表字段有哪些，我们是用微服务还是不用，我们的模块应该怎么划分等等这些实现上的问题。建立业务模型的目标在于勾勒出用户业务的全景，充分的通过与用户的沟通来了解用户的核心问题域，也就是用户最想解决哪些问题，什么对他是最有价值的。并且，通过业务模型，用户和开发之间、开发人员内部有了一种共同的沟通语言，而不是像前面的例子那样用技术的语言进行信息传递。所有人都可以更好的理解和传达业务领域的各种概念，尽量的做到客户的需求、意图、业务知识被正确的理解，没有遗漏。
具体怎么建模，DDD提出了一套方法论。这次的活动中对这些方法有了一个初步的体验。
1、注重从用户那里沟通了解其需求。
2、梳理用户业务的流程、规则。
3、从需求、流程中找到用户的核心问题域（演讲中以京东的物流，淘宝的多商品种类为例进行了大致比喻）
4、从核心问题域中识别子领域。子领域的识别实际上是对复杂问题的分治法。各个子领域之间会存在相连接的边界，边界两侧会出现各自子领域中同名业务对象的连接，这种连接我理解为各个子领域之间的业务转换桥梁。例如，在一个电商系统例子中，如果存在订单管理子领域和物流管理子领域，那么两个领域中都会有订单这个对象，这时业务上来说订单是订单子领域向物流子领域流转的载体。我想这种跨领域存在的同名对象的关系和作用应该不止我想的这一种，后续再慢慢学习体会。另外，也可以从子领域中识别出公共领域的情况，例如订单和物流子领域中可能就会抽取出商品领域这个公共领域。我想这些子领域的识别，就是后续在技术实现层面上对模块、服务的一种划分参考。例如商品领域可以作为核心服务，订单领域和物流领域作为composite服务。
5、上面的过程反复迭代
至于有了业务模型之后，如何将它转化到代码上，又如何与系统架构、技术架构结合，目前还没有太多体会，后续再深入了解下DDD看看它是如何来解决这个问题的。
通过这次活动，个人体会是如果将业务与代码之间的关系做一个比喻的话，那么业务是因，代码是果。在未来引起变化的主要原因是业务，然后才是代码随之变化。那么我们建立解决问题的模型，一开始从代码这个果来出发的话，就是本末倒置了，这种角度出发得到的技术模型也必然很难适应真正引起其变化的原因 - 业务。也许反过来从业务这个原因出发对问题进行建模，并且让这个业务模型具有可扩展性，对变化是开放的，那么代码这个对业务模型的实现者和表象也应该可以具有相差不多的可扩展性吧。
