领域驱动设计对于前端的启发（一）
02:09
阅读次数： 0在领域驱动设计这一本书中，其实没有着重说明只能用在前端或者后端。 领域驱动设计是对于所有的软件工程来说的，所以，领域驱动设计也一定能用在前端领域中。
子域
这一个概念，其实对于所有写代码的人都应该熟悉。 好的代码需要是高内聚，低耦合的。 子域也要求代码呈现高内聚，低耦合的特征。 确定子域的边界，其实就是确定内聚的代码的边界。
贫血的架构
在前端领域，有一类项目架构是非常粗暴的。 类似于
-app
-api
-components
-router
-pages
可以看到，在app目录下面，按照文件的类型，把不同的文件放在一起。 有人会说，这样看起来不错，因为如果我想去改api接口的时候，我就会去api文件夹下找，想找组件的时候，就会去components文件夹下方去找。
但是，这样的架构到最后就会出现问题。
所有的api都聚集在api目录下，可能有几十个文件。 所有的组件都在components下，得一个个点开查找。
当这种架构要进行迁移的时候，你就得从api中找到和这个组件用到的api接口，然后把他提取出来。 如果这个api用在了别处，还需要看看其他组件是否会受到影响。
这种架构，就是贫血的架构，在领域驱动设计中，这种架构就是指：各种组件的数据源，行为，表现，分散开了。无法把他们聚合在一起。
贫血，就是指一个生物，只有骨架，没有血肉，没法进行行动。
改进的架构
基于对贫血架构的改进，我们的前端架构可以改成下面这种：
-app
-order
-components
-api
-hook
-page
-subpage
对于order这一个页面，我们有这个页面用到的所有组件，api接口，还有hook。 而且，我们能通过子页面，或者子组件来把模块组织成一个树状结构。
这样的架构，可以改进之前的贫血架构的一部分，数据，展示，逻辑是放在了一起。
但是，这样的架构还是有一定的缺点的。
例如，如果某一个subpage 中的内容要夸页面，移动到其他的位置，就还是得从components中一个个把组件抽离出来。
对于前端来说，页面展示的变化是比较频繁的。对于这样的架构，无法应对频繁变化的展示逻辑。
严格的分层架构
对于更好的前端架构，其实已经有人实践了
对于react的项目，可以看看bulletproof-react的项目。这个项目严格规定了文件的位置。
项目的思想，其实就是分为三层，展示层，逻辑层，数据层。
数据层就是api的接口等其他数据来源。
展示层就是app目录
src
|
+-- app # application layer containing:
| | # this folder might differ based on the meta framework used
| +-- routes # application routes / can also be pages
| +-- app.tsx # main application component
| +-- provider.tsx # application provider that wraps the entire application with different global providers - this might also differ based on meta framework used
| +-- router.tsx # application router configuration
+-- assets # assets folder can contain all the static files such as images, fonts, etc.
|
+-- components # shared components used across the entire application
|
+-- config # global configurations, exported env variables etc.
|
+-- features # feature based modules
|
+-- hooks # shared hooks used across the entire application
|
+-- lib # reusable libraries preconfigured for the application
|
+-- stores # global state stores
|
+-- testing # test utilities and mocks
|
+-- types # shared types used across the application
|
+-- utils # shared utility functions
和app同级别的目录，都是shared的依赖，属于项目中可以共用的。
features其实就是domin。features的同级子feature之间不能之间引用，所有的features中的资产，都只能在app目录中引用。
这样的好处有：
app被严格的当成了展示层，展示层的频繁变动，只用修改app目录中的文件。
features之间不能直接引用，features内部，自己就包含了api，components等，也就是features内部是充血的。
具体的其他约束，还是请看bulletproof-react这个项目的介绍。