2025-5-20
书中把距离 IO 近的组件成为底层组件，认为低层组件容易变更
回到业务，稳定的逻辑应该放在高层，那么咱们的业务里跟 IO 对应的可能就是协议了。
pucch 组件的核心业务逻辑：给 UE 分配资源。
小区级业务是插件，RB 自适应也是插件
推荐书籍：
在这里，再次推荐读者仔细阅读Ivar Jacobson关于软件架构设计的那本书：Object Oriented Software Engineering，请读者注意这本书的副标题：A Use Case Driven Approach（业务用例驱动的设计方式）。在这本书中，Jacobson提出了一个观点：软件的系统架构应该为该系统的用例提供支持。
什么是业务实体：整个系统的关键业务逻辑（假设给系统做极致减法，做到最后都不应该被减掉的部分），业务实体要能被其他不同应用复用。主义要体会感受一下这个“复用“的概念，被复用，也就是重复使用，说明它的价值非常高，很多组件都需要它。
什么是用例：这个不是我们所说的测试用例。这个用例通常包含特点场景下的业务逻辑。
跨越边界：
图22.1
k假设某些用例代码需要调用展示器，这里一定不能直接调用，因为这样会违反依赖关系原则：内层圆的代码不能引用外层的声明。我们需要让业务逻辑代码调用一个内层接口（图22.1中的“用例输出端”），并让展示器来负责实现这个接口。
跨越边界的数据应该越简单越好，不要投机取巧直接传递业务数据结构。
22章最后一个组件图，打印出来，自己画出来。现在就画。
UML类图
空心箭头指向被父类（继承）
实现箭头指向被依赖的对象，可以是成员变量，入参