「这是我参与11月更文挑战的第10天，活动详情查看：2021最后一次更文挑战」
因为我们面试了对应的这个 Java 开发的岗位是对业务负责的，因此我们需要做的是能够阐述清楚我们在之前的项目过程当中所采用的一些业务架构的一个思想，以及我们强调的我们的一个领域模型的设计。
在业务架构当中，由于我们负责的是商品系统和对应的交易系统，因此我们挑两个最简单并且对应最有特色的一个流程，分别是商品系统的一个商品详情页的查询，以及交易系统的一个下单支付的流程。
那在介绍整个对应的商品系统的一个商品详情页的能力上面，我们一定要凸显我们对应的一个亮点。
虽然一个商品详情页的一个查询能力看似只有一个简单的接口，但是我们所用的是基于领域驱动式设计的一个领域模型的思想。
我们整个的一个商品基础是分为商品、品牌、类目、库存、详情描述以及销量、价格和运费，那么多对应的一个设置去做我们的一个商品的领域模型的。
那试想一下，如果说我们是初学对应的一个 Java 开发的应用，我们肯定会把对应的这样的一个商品信息全部放在一张商品表里边，并且用不同的字段去做对应的一个区分。
我不排除这样做是有对应的一个好处的，因为它的模型非常的简单，而且整个的查询、存取以及加缓存的逻辑都会变得很简单。
但是随着我们的用户量以及整个的一个系统体量的上涨，我们的业务的不断更新，就会发现我们整个的商品的这样的一张表对应的这个结构就会变得非常的复杂，不同的结构、字段之间都会有对应的一个来回的关系。
因此我们强烈推荐大家采用领域驱动式的一个设计方式，不要先从数据库维度去考量你的一个应用应该设计成什么样，而是应该先从领域模型的一个维度去拆分清楚你对应的这样的一个商品模型，会以哪些领域驱动的维度去做对应的一个能力，再去考虑数据库的一个设计。
接下来我们一起来看一下，我们对应的这样的一个商品系统应该怎么去做领域驱动式的一个设计。
那我们仍然但是一样的，在跟面试官介绍我们对应的商品模型之前，首先我们自己要非常清楚我们的一个商品的模型的核心，商品模型的核心毫无疑问就是我们的一个商品基础模型。
在这个商品基础模型内会有一些非常容易能够理解的字段，比如说商品 id 以及商品名，还有类似于像对应的一个商家 id 等等这样的一些内容，代表了对应的这个商品是属于哪一个商家所发布的。
那这个就是我们的对应的一个商品的基础模型，它非常的简单，并没有太多复杂的一个逻辑。
随着对应的商品模型之外，我们会有一个品牌模型，因为我们的商品会关联对应的一个品牌，于是乎我们有一个品牌模型，那这个品牌模型会有一个品牌 id 以及品牌名，还有类似于像授权体系这样的一些内容都可以落在我们的品牌模型上。
商品模型和品牌模型之间的一个关联关系，很显然也是多对多的一个关系，但是我们就在商品模型的视角上来看，一个商品模型肯定只会关联一个品牌模型，代表的是这个商品属于对应的哪个品牌。
那除了品牌模型之外，我们还有对应的一个类目模型，代表了我们这个商品属于对应的什么样的类目分类。在类目模型内，我们仍然会有一个类目 id 以及它的一个类目数的结构，那我们对应的这个类目数仍然不以数据库维度去做设计，整个的这个类目数类似于我对应的商品是挂在我们的一个底层的类目下，例如卫衣这个类目，然后它有它的一个父类目代表男装，以及在这个男装上面会有服饰相关的一个一级类目。
因此一个商品模型我们会变成一个对应的、有一些基础的一个类目属性，除了对应的这个类目模型之外，我们还会有对应的一个库存模。
为什么我们把库存模型要单独进去说呢？其实我们对应的在整个的一个交易流程上面，往往我们对应的一个库存的能力和商品的能力是分隔开的，因为一个商品代表了它的一些展示类的一个信息。但是库存代表了它的交易类的信息，往往会在整个的一个交易下单的流程里，会对这个库存产生各种各样的一个原子的一个减操作，包含了对应的一个抢购的场景，因此库存模型是需要非常好的设计的。
撇开对应的一个库存 id，我们一般会有对应的一个库存数量，也就是你有哪些对应的数量，以及它的一些分仓相关的一些逻辑，就是我们对应的一个库存可能是会有分仓的，一个商品在不同的地域它的库存是不一样的，但于是乎一个商品模型也会关联一个或者多个对应的一个分仓的模型。
然后我们会有一个单独的一个商品详情的内容，我们还记得我们有一个详情模型，我们还记得类似于像淘宝对应的一个商品详情的内容，其实内部是有很多详情的信息的，这些的详情的信息内容非常的复杂，有图片、有文字、有类似于副文本这样的一些组件。
因此整个的这个详情模型，一般来说在前端的页面上都是异步加载的，因此我们对应的详情模型单独分类开来，去做对应的详情内容的设计。
那于是我们对应这个商品模型还会关联一个详情对应的模型，那它对应的也是一对一的一个关系。
然后我们有了库存，自然而然就会有对应的一个销量，我们对应的一个销量模型也是和交易属性挂钩的，一般来说卖掉一单之后整个的销量会加 1，于是它会有对应的一个销量的一个数量。
我们的一个商品的基础模型就会关联到一个销量模型的销量数量上，然后我们还有最复杂的商品的一个价格体系，那商品的价格体系我们一般也会把它抽取对应的一个价格模型，它有对应的一个价格计价以及对应的一个价格类型。
为什么我对应简单的一个价格需要有一个单独的模型去承载？
我们对应的一个淘宝，对应的一个商品的价格在不同的时期是不一样的。我们有对应的一个商品的基础价格代表了平销期，它的一个价格一旦进入双十一、双十二的活动，并且在活动倒计时以及对应的一个预热期内，它的一个整个的价格的显示模型和显示策略是完全不一样的，于是乎不同的价格类型、不同的计价方式都映射到了这个商品的计价模型上。
那因此我们对应抽象出一个价格模型，涵盖了所有的价格计算，在整个的商品的交易和显示的过程当中都是非常有必要的。
最后我们应该有一个对应的一个运费模型。在整个的这个运费模型的基础上，我们都可以看到，一般来说商品会有一些运费的设置，包含是否包邮，以及它如果不包邮的话，它的运费计算的规则是怎么样的。
因此我们对应的一个商品的基础模型上，也会包含了对应的一个运费计算相关的一些运费的一个能力。
我们的面试官其实就可以非常深刻地理解到，你不仅仅是满足于对应的整个一个商品、业务能力的一个 CRUD 的展示形式的一个设计，而是会全盘地去考虑你作为一个商品的一个系统的基础，它所要承载的一些能力，完完全全都通过领域模型的思想去做拆分。
然后这些领域模型的思想落到对应的数据库的设计内，可能是一些一对一或者一对多的表，也有可能将对应的这些模型的内容移到对应的同一张表里。 不管是采用哪种数据库的设计，在你介绍对应的你的业务架构的过程当中，面试官就可以深刻地理解到你对应的一个商品基础的一个能力，其实是可以用领域设计模型的一个思想去做对应的一个设计和阐述的，面试官对你的一个能力也会有一些业务方面的肯定。
