<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on elonnzhang</title><link>https://jiabin.dev/categories/architecture/</link><description>Recent content in Architecture on elonnzhang</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sat, 11 Jan 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://jiabin.dev/categories/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>领域驱动设计（DDD）基础</title><link>https://jiabin.dev/blog/ddd/</link><pubDate>Sat, 11 Jan 2025 00:00:00 +0800</pubDate><guid>https://jiabin.dev/blog/ddd/</guid><description>&lt;p&gt;&lt;strong&gt;限界上下文之间的映射关系&lt;/strong&gt;&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。&lt;/li&gt;&#10;&lt;li&gt;共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。&lt;/li&gt;&#10;&lt;li&gt;客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。&lt;/li&gt;&#10;&lt;li&gt;遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。&lt;/li&gt;&#10;&lt;li&gt;防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。&lt;/li&gt;&#10;&lt;li&gt;开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。&lt;/li&gt;&#10;&lt;li&gt;发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。&lt;/li&gt;&#10;&lt;li&gt;大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。&lt;/li&gt;&#10;&lt;li&gt;另谋他路（SeparateWay）：两个完全没有任何联系的上下文。&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;&lt;strong&gt;实体&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;当一个对象由其标识（而不是属性）区分时，这种对象称为实体（Entity）。&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;例：最简单的，公安系统的身份信息录入，对于人的模拟，即认为是实体，因为每个人是独一无二的，且其具有唯一标识（如公安系统分发的身份证号码）。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;值对象&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象（Value Object）。&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;例：比如颜色信息，我们只需要知道{“name”:“黑色”，”css”:“#000000”}这样的值信息就能够满足要求了，这避免了我们对标识追踪带来的系统复杂性。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;值对象很重要，在习惯了使用数据库的数据建模后，很容易将所有对象看作实体。使用值对象，可以更好地做系统优化、精简设计。&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;它具有不变性、相等性和可替换性。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;在实践中，需要保证&lt;strong&gt;值对象创建后就不能被修改，即不允许外部再修改其属性&lt;/strong&gt;。在不同上下文集成时，会出现模型概念的公用，如商品模型会存在于电商的各个上下文中。在订单上下文中如果你只关注下单时商品信息快照，那么将商品对象视为值对象是很好的选择。&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;聚合根&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;Aggregate(聚合）是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p align="center"&gt;&lt;img src="https://jiabin.dev/assets/img/ddd-dto-do-po.png" width="200" /&gt;&lt;/p&gt;&#10;&lt;p&gt;首先领域的开放服务通过信息传输对象（DTO）来完成与外界的数据交互；&lt;/p&gt;&#10;&lt;p&gt;在领域内部，我们通过领域对象（DO）作为领域内部的数据和行为载体；&lt;/p&gt;&#10;&lt;p&gt;在资源库内部，我们沿袭了原有的数据库持久化对象（PO）进行数据库资源的交互。&lt;/p&gt;&#10;&lt;p&gt;同时，DTO与DO的转换发生在领域服务内，DO与PO的转换发生在资源库内。&lt;/p&gt;&#10;&lt;p align="center"&gt;&lt;img src="https://jiabin.dev/assets/img/ddd.png" width="400" /&gt;&lt;/p&gt;&#10;&lt;p&gt;&lt;img src="https://jiabin.dev/assets/img/ddd-mt.png" alt=""&gt;&lt;/p&gt;</description></item><item><title>数据库与消息队列笔记</title><link>https://jiabin.dev/blog/database-and-mq-notes/</link><pubDate>Sat, 11 Jan 2025 00:00:00 +0800</pubDate><guid>https://jiabin.dev/blog/database-and-mq-notes/</guid><description>&lt;p&gt;面试知识&lt;/p&gt;&#10;&lt;h2 id="数据库"&gt;数据库&lt;/h2&gt;&#10;&lt;p&gt;索引：&#10;事务&#10;隔离级别&#10;锁 &lt;a href="https://www.notion.so/elonnzhang/23d21f3fbf218061963dee831cdecd91?source=copy_link"&gt;https://www.notion.so/elonnzhang/23d21f3fbf218061963dee831cdecd91?source=copy_link&lt;/a&gt;&lt;/p&gt;&#10;&lt;h2 id="消息队列"&gt;消息队列&lt;/h2&gt;&#10;&lt;p&gt;通常来说，使用消息队列主要能为我们的系统带来下面三点好处：&lt;/p&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;异步处理&lt;/li&gt;&#10;&lt;li&gt;削峰/限流&lt;/li&gt;&#10;&lt;li&gt;降低系统耦合性&lt;/li&gt;&#10;&lt;li&gt;分布式事务、顺序保证和数据流处理。&#10;可能会遇到的问题&lt;/li&gt;&#10;&lt;li&gt;消息丢失、重复消费&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;h3 id="kafka"&gt;Kafka&lt;/h3&gt;&#10;&lt;p&gt;发布-订阅模型 : 1 -&amp;gt; N&#10;&lt;img src="https://jiabin.dev/assets/img/p-t-c.drawio-2.svg" alt="发布订阅模型"&gt;&lt;/p&gt;&#10;&lt;p&gt;发布订阅模型（Pub-Sub） 使用&lt;strong&gt;主题（Topic）&lt;/strong&gt; 作为消息通信载体，类似于&lt;strong&gt;广播模式&lt;/strong&gt;；发布者发布一条消息，该消息通过主题传递给所有的订阅者，&lt;strong&gt;在一条消息广播之后才订阅的用户则是收不到该条消息的&lt;/strong&gt;。&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;在发布 - 订阅模型中，如果只有一个订阅者，那它和队列模型就基本是一样的了。所以说，发布 - 订阅模型在功能层面上是可以兼容队列模型的。&lt;/strong&gt;&#10;&lt;img src="https://jiabin.dev/assets/img/kafka%20%E6%9E%B6%E6%9E%84.png" alt=""&gt;&#10;Kafka 比较重要的几个概念：&lt;/p&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;&lt;strong&gt;Producer（生产者）&lt;/strong&gt; : 产生消息的一方。&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Consumer（消费者）&lt;/strong&gt; : 消费消息的一方。&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Broker（代理）&lt;/strong&gt; : 可以看作是一个独立的 Kafka 实例。多个 Kafka Broker 组成一个 Kafka Cluster。&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;p&gt;同时，你一定也注意到每个 Broker 中又包含了 Topic 以及 Partition 这两个重要的概念：&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;&lt;strong&gt;Topic（主题）&lt;/strong&gt; : Producer 将消息发送到特定的主题，Consumer 通过订阅特定的 Topic(主题) 来消费消息。&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Partition（分区）&lt;/strong&gt; : Partition 属于 Topic 的一部分。一个 Topic 可以有多个 Partition ，并且同一 Topic 下的 Partition 可以分布在不同的 Broker 上，这也就表明一个 Topic 可以横跨多个 Broker 。&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;分区进一步理解&lt;/p&gt;</description></item></channel></rss>