Catalog微服务使用传统的Data Service/CRUD API模式，将Entity Framework Core的DbContext以构造器注入的方式注入控制器（Controller），然后在控制器中完成业务操作和数据访问，后台采用SQL Server数据库
Ordering微服务使用CQRS体系结构模式，它的运作完全基于领域事件，虽然它并非完全实现CQRS模式的所有细节，但已经足够实现它的业务逻辑，并且它的复杂度也得到了很好的控制，它后台也是采用SQL Server数据库
Basket微服务使用基于领域驱动设计的分层模式，它引入了领域模型、仓储等概念，并将仓储的实例通过构造器注入的方式注入控制器，然后让控制器充当领域驱动设计中应用层的角色，完成业务处理和领域模型的重建和持久化，后台采用Redis缓存作为数据持久化机制
这些微服务之间通过RabbitMQ（或者Azure Service Bus）的事件总线（Event Bus）完成通信，以编排式的Saga模式实现了基本的分布式事务，整个后端架构都是容器化的，运行在容器编排集群中（docker-compose或者Kubernetes）。 由此可见，在微服务的架构风格中，领域驱动设计能够被更加灵活地运用，由于不同的微服务是由不同的团队负责开发，因此就可以在不同的微服务中，以不同的程度来引入领域驱动设计的思想以辅助解决业务分析与系统开发中的难点，最终达到整个软件架构的良性发展。 软件架构风格大致就介绍这些吧，涉及的内容确实很多，也没有办法在一篇文章里完全写完，以后有机会再深入补充吧。
总结读到这里，你应该已经大致了解了什么是领域驱动设计、软件架构模式与软件架构风格的区别是什么、常见的软件架构风格有哪些，以及在不同的软件架构风格下，领域驱动设计是如何对软件的架构设计提供指引并指导模式的合理使用。你还会了解到，很多情况下，对于绝大多数项目而言，或许一个面向数据的CRUD服务已经完全能够满足你的应用系统需求，或许你也只需要一个单体架构（Monolithic）就能够解决你眼下乃至几年内的开发痛点，那么在这些情况下，你需要慎重考虑是否真的需要“赶时髦”地引入过于复杂的架构风格和架构模式。然而另一方面，在团队相对比较成熟、对领域驱动设计有一定认知和认同、成本允许的前提下，能够鼓励大家尝试实践领域驱动设计，这也是一件非常好的事情，毕竟有学习有实践才会有进步。所以，何时使用领域驱动设计？应该选择什么样的架构风格？还是你自己来决定吧。
参考阅读借此机会推荐一些非常优秀的“课外读物”，这些著作的经典程度不亚于《设计模式：可复用面向对象软件的基础》（GoF95）一书之于面向对象分析与设计（OOAD）的经典程度。如果有兴趣，推荐参考阅读：
《领域驱动设计：软件核心复杂性应对之道》：Eric Evans
《企业应用架构模式（PoEAA）》：Martin Fowler
《面向模式的软件体系结构：卷一：模式系统》
《面向模式的软件体系结构：卷二：用于并发和网络化对象的模式》
《实现领域驱动设计》：Vaughn Vernon
《微服务架构设计模式》：Chris Richardson
《.NET Microservices：Architecture for Containerized .NET Applications》电子书：Microsoft
此外，我自己也有几个Github Repo，虽然很久没有更新了，但当时也是在一定程度上以各种不同的架构风格，采用了不同的架构模式实现了领域驱动设计（在上面文章中也已经提及这些Repo，这里总结一下）：
分层架构案例：Byteart Retail：https://github.com/daxnet/byteartretail
事件驱动型架构案例：WeText：https://github.com/daxnet/we-text
基于.NET Core的领域驱动设计开发框架：https://github.com/daxnet/apworks-core
十多年前，我也总结了不少领域驱动设计的文章，完整列表在此，也可以参考了解一下。