定义了数据结构，但是不抽象数据的业务逻辑，直接让使用方操作成员变量，或者定义一堆成员变量的 get/set 接口。

这句话含义是DDD中的贫血模型了。比如我需要判断某个实体是否是合格的，需要通过a,b 字段来判断。这个实现没有定义在数据结构里，却把a,b字段通过get暴露出去，让调用方去判断了

目前来看，架构设计套路有限，但业务领域无限。如何应用有限的套路做出无限的架构设计，难点应是在业务上。没有足够的业务背景积累和业务需求洞察，架构设计就会出现知易行难的窘境。但是想要架构师一步到位具有健全的业务领域知识也是不现实的。所以，横竖都不好，那么就落地灵活的设计，动态去演变，也就所谓的演进式架构。而代码变动是高成本的，所以要想办法降低成本。首先代码可读要高。接着，单模块内各层，以及模块间的耦合要低。最后，代码的实现要采用合适的设计模式，以便易于扩展。但这三点不取决于架构师，具体业务开发个人素养的影响更大。所以，感觉约往后，业务开发的个人素养要求会越高。至少领域设计（战略规划）和架构分层、设计模式（战术应用）的诉求怕是少不了的。

老师今天课程中提到了一个很关键的现状：框架绑架开发。这其实是许多程序过程中经常碰到的问题：某种框架不错大家去用，可是随着业务的复杂度和需求的复杂度的增加我们会发现被框架绑架了-实现不了，然后就开始调整需求或者实现方式。
     这些年更多基于内核或者核心去改/写框架的：稍微有点特色就火了；其实我们去看本质会发现，只是降低了对某些框架的绑定能力而已，当程序中一大堆框架时其实我们就被一大堆事物绑架了。框架使用的度确实是个问题：用的越深绑架越深，故而其实都是在努力的做解绑-最小需求使用。
     以上是个人的一点切身体会和薄见：一路听老师的课一路学习修正；期待老师的后续分享。

理清楚需求 列出验收标准 让一线开发理解做成啥样OK 有一些感触👍🏻

目前我们这的架构师基本不做需求分析，需求分析都是SA-系统分析师在做，当SA对其中有些技术点拿不准的时候才去咨询架构师，而部分架构师就确认下什么功能放在什么系统，什么功能这个系统不应该做==，非常机械。

“追求的不再是架构设计的好坏，而是打补丁，怎么把里程碑的目标实现了，别影响了团队绩效“ 。绩效真是把双刃剑，也许在做架构的时候也要充分将这些管理、协作因素考虑进去。

“代码即文档。代码是理解一致性更强的文档。“ 现在小孩子都开始抓编程，编程语言也真正变成一种语言，与计算机沟通、与 IT 人员沟通的语言。

数据结构是指的是表结构或者是实体吗？还是什么链表，栈，树之类的数据结构呢？

本身也应该按module 来切分代码模块，最好让模块多具备正交性。

许老师好，现在有些SaaS 企业PaaS化，请问从SaaS 向PaaS 过度的关键技术是什么呢？在系统架构上两者有什么本质区别吗？望不吝赐教。

定好边界，提前抽象出各个子模块对接时的接口与数据，然后是各个子模块的结构。架构师之路，道阻且长