主要观点：开发者喜爱布尔值，因其能完美映射计算机底层工作且便于与if语句配合，但用于领域建模时会引发问题，应采用枚举和枚举集来替代。
关键信息：

• 以门的模型为例，最初用布尔值表示门的状态（开或关），后来添加锁的状态后出现四种可能状态，其中一种（开且锁）不合理，增加了代码复杂度和测试负担。
• 在实际专业经验中，项目的Company实体最初用isPaying: boolean表示是否付费，后来出现“合作伙伴公司”等情况，不断添加布尔值标志，导致状态组合过多且难以处理。
• 更好的方法是用枚举和枚举集来表示状态，如Door用enum DoorState，Company用enum ContractStatus等，可减少状态组合，便于测试和处理。
• 不应完全避免布尔值，可将其用于技术部分而非业务逻辑或领域建模，如自定义集合的hasElement方法用布尔值合适。
• 用枚举为基础构建状态机，如门的状态转换表，但对业务逻辑使用状态机需谨慎。
  重要细节：
• 最初用布尔值表示门的状态时，代码简单，但添加锁的状态后出现问题，如可能出现不合理的状态组合。
• 在Company的例子中，最初用isPaying表示付费状态，后来不断添加布尔值标志，如isPartner、isAIEnabled等，导致状态组合过多。
• 用枚举和枚举集表示状态后，可更清晰地定义状态和处理相关逻辑，如对于全套餐的额外功能，可通过枚举和集合来判断。
• 对于不可达状态，虽然难以完全避免，但可通过合理设计减少其影响，且比大量布尔值更易测试和防范。