阅读笔记-以领域驱动为基础进行的架构设计

读书要善于总结，形成自己理解的方法论，允许自己理解的不清晰，但是绝不能只看到别人的牛逼，自己却没有收获。
要勇于承认自己有多菜逼，并且持续学习，机会来的时候，自己要能够把握。
为每天领悟到新的知识而欣喜若狂，为原来自己有多sb而黯然神伤。

学习文章：
1、 领域驱动设计在重构业务系统中的实践
2、基于支付场景下的微服务改造与性能优化

一、 《领域驱动设计在重构业务系统中的实践》学习体会

1、领域驱动模型（DDD）英文是domain driven development，直翻是领域驱动开发。

2、需要领域驱动设置的是：业务重构环节，初期搞项目的时候，其实完全不需要领域驱动设计，快速迭代开发是主流，毕竟出活才是公司的首要需求。只有业务增长到了一定程度，各业务服务直接耦合严重，新增需要响应时间出现问题，我们需要重构一个核心系统解耦复杂业务问题的时候，才需要领域驱动设计。

3、领域驱动设计的核心概念：领域通用语言（UBIQUITOUS LANGUAGE）、领域模型（Domain）、限界上下文（Bounded Context）。

4、感觉作者问题还是没有交代的特别清楚啊，可能我也不怎么了解这种商超系统吧。
个人理解他的问题：得到有很多可以购买的商品，包括专栏、罗胖推荐的书、大师的课程、付费的音频等等，有n多种商品，商品的购买要调用多个系统，耦合的太严重了，中间虽然搞了个订单系统，其实没有解决啥问题，只是订单号能把业务信息串起来了，但是这个订单系统就是记录个订单信息，系统还是耦合在一起的。没办法，还是有问题。
可最关键的问题是什么呢？
是不是现有的系统完全解决不了财务那边的问题，财务结算的时候完全不知道业务方提供的数据 和支付提供的数据完全对不上？
后来产品说，怎么这的订单号不是统一的，统一后就搞定了，可是搞了个订单系统后，完全把业务搞的更复杂了？

怎么感觉都是先把事说明白了，再套领域驱动设计比较好。。。。

反正最终琢磨出来的是一个订单交付系统，前面有个交易中心，负责支付处理，支付成功后交付系统，交付系统负责调用具体的业务系统履约，这个系统的主要目的是搞权益确认的。用他的话就是 “交易是行为，订单是契约，交付是履约”，后面的财务系统不用跟业务系统对接了，直接跟这个订单交付系统对接就可以了。

5、切忌以用户为中心去分析业务，分析的时候记得机场的例子。

以上

二、 《基于支付场景下的微服务改造与性能优化》学习体会

1、微服务的基础？微服务提现的真谛最终还是理解业务，只有深入了解业务才能结合领域来重新定义微服务。微服务的特点是去中心化。

2、自己也亲身参与过聚合支付系统的设计开发，说实话，自己真的还没有按照文章中理解的深度去总结过怎么设计实现一个支付系统，往往自己对外输出的时候，都是基于以往的认知去输出，并没有整体上去考虑过。先宏观后细节，先业务后架构搭建。不过聚合支付和真的3方支付还是有点区别的，哈哈。

3、常见的互联网支付方式：刷卡支付（刷卡、扫描手机生成的二维码）、扫码支付（手机扫一扫）、公众号支付（微信、支付宝app内支付）、h5支付（wap网页唤醒支付功能）、app支付（app调用支付sdk）、网银支付（唤醒网银）、快捷支付（手机短信口令）

4、按照文中画的 确实更准确了，也能感觉出来领域和界限上下文的区别，主要是界限上下文，字面意思感觉是边界接口呢，其实不是，就是领域内的组成部分，可以是一个系统、一个应用、一个服务或一个组件。从这里理解，领域模型的目标也是抽象和分层。

image.png

5、微服务具体要拆分到什么程度，跟业务规模、复杂度、公司情况相关的，要结合实际，选择合适的分层方式，不要一开始搞的那么细，没法落地，注意产出。先搞模块，合适的时机再拆分服务。