这两个概念从了解DDD开始就有这个疑问，为什么叫domain driven design,而不是business driven design，我们平常都叫业务，从没讲过领域，难道是国外与国内叫法不同，但也不至于啊，给别人介绍DDD时，也会被问到底什么是domain，为什么不是BDD呢？当然，现在DDD被提多了，人们也不像刚开始时那么追问了，顺其自然地接受了，但疑问还在 application service编排业务流程，domain service编排领域，看来是对了，但我们的业务好像都比较简单，是不是只有业务横长，领域纵深的才需要同时业务建模和领域建模呢 当前我们是做票税业务的，接受发票，验真发票，认证抵扣，同步发票(更新由其他系统来的发票状态，也会再同步发票数据到下游系统)；整体看很简单，但复杂在状态同步，首先会多各个业务系统得到状态，比如报销系统来同步发票的报销状态，SAP系统来同步发票记帐状态等等，各个系统都会来写点东西，再把这些发票数据同步到下游系统，但同步下游时就麻烦了，有些客户需要在接受到记帐状态时同步，有些需要在接受到报销状态时同步，各种交叉同步； 从整体系统看似乎只有业务流程，没有领域问题，似乎一个状态机就搞定了，用流程引擎串业务感觉又太重，但现实又复杂得多，看着没法建模，微服务也拆得奇形怪状 像这样流程长而领域浅的系统不知道怎么玩了