一、读前思考问题
解决系统边界问题的原则、规则，关于系统边界的原则、规则，你们觉得可以有哪些呢?
二、康威原则
Organization which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
设计系统的组织其产生的设计等价于组织间的沟通结构
Conway’s law reversed: You won’t be able to successfully establish an efficient organization structure that is not supported by your system design(architecture)。
如果你的系统架构不支持，你无法建立一个高效的组织架构。如果你的组织架构不支持，你也无法建立一个高效的系统架构。
一张关系图
个人思考
系统本质上是一个组织结构下为了实现某种业务的产物，如果想要聊系统边界和原则，那么一定要基于当前的组织结构来如何更加简单、高效的解决业务问题原则来考虑。
三、场景介绍
以下三个场景主要是基于当前的组织结构已经明确的情况下，经常会遇到的三个场景：
3.1、基于需求聊系统边界场景
3.1.1、 设计目的-解决了什么问题-明确问题域
需求的价值，需求的真实目的是为了解决什么问题？ 比如一场活动营销带来多少GMV的提升，一个新的功能产品能够带来多少的用户留存。从需求解决什么问题来划定属于营销域，还是属于交易域、订单域。
3.1.2、识别功能需求和非功能需求范围
一个需求的完整实现，往往需要一系列链路上的产品功能和非功能产品叠加。我们需要识别功能需求范围，来更好的划分为前端系统、后端系统、界面UI等。
3.1.3、质量属性场景
随着现有互联网业务的发展，业务的变化多种多样，每个老系统都具有一定复杂度，因而大部分进行了重构微服务拆分，即使没有做应用物理隔离，也会做逻辑隔离，因而需要识别到某个场景下。
3.1.4、约束条件
比如工时、人力、改造成本、可扩展性、未来规划战略等条件进行权衡。
3.2、基于产品聊系统边界场景
3.2.1、产品的定位
产品系统有什么？用户是谁？
3.2.2、产品的能力范围
目前哪些是我们产品系统涵盖的能力范围之内
3.2.3、产品的成熟案例
目前的业务成熟案例，更倾向于把哪些内容做深、做好
3.2.4、产品的扩展能力和规划
对于不属于自己产品能力范围内的，我们系统后续的迭代规划，如果不在未来规划，也可能不适合我们
3.3、基于系统聊系统边界场景
3.3.1、符合正交性
对应一个好的应用，一定会去衡量正交性，是否该系统目前是高内聚、低耦合的，对于可扩展的与系统本身不变的呈正交。
3.3.2、符合SOLID原则
该系统实现以后一定是符合SOLID设计原则
3.3.3、符合高内聚、低耦合
在系统设计的时候要考虑到业务实现的内聚性和耦合性
四、个人总结
聪明的读者你在聊系统边界与规则的时候，是否遇到过困难，如果遇到了，可以尝试下笔者的方案哦！
