在采用DDD进行开发的时候，我们要优先做领域建模，不要过早关注底层数据库的实现。
更不要采用”先建数据库表，再建实体类”这样的”数据库驱动”的开发模型，我们只把数据库作为一个保存数据的持久层技术即可。
但是，我们也要给予数据库适当的关注，因为数据最终仍然是持久化在数据库中的，如果一味地追求DDD的原则而不追求性能优化，就犯了教条主义错误。
软件设计和开发过程中的一切原则都不是不能突破的，解决实际问题是一切原则、技术的出发点。
尽管通过DDD模式编写的数据库操作的代码并不是性能最优的，但是只要没有遇到性能瓶颈，我们就不需要采用”手写SQL语句”等方式，以免犯”过早优化”的错误。
“过早优化”是很多开发人员容易犯的一个错误。
代码是由开发人员写出来，一名合格的开发人员对于程序的优化有着天然的追求，这是一件好事，也是优秀的开发人员区别于平庸的开发人员的一个明显标志。
但是，一名开发人员在进行程序开发的时候，如果没有全局的意识，过早关注局部的程序性能优化，就可能会导致时间资源投入不合理。
因此开发人员应该对于项目的优化目标进行选择，把精力放到重要的事情上。
从逻辑上来讲，不同的微服务应该管理自己的数据库，因此不同的微服务不应该共享同一个数据库。
当然，出于便于DBA(Database Administrator)管理等考虑，也许多个微服务的数据库表被暂时放到了同一个数据库中。
但是以后我们可能会把微服务的数据库表迁移到独立的数据库服务器上，因此我们要避免在业务层面的代码中进行跨服务的数据库表联合查询。
在一个服务内部，由于聚合之间通过聚合根的标识符来引用，因此为了减小表之间的耦合度，并且降低以后把某个聚合拆分为单独服务的难度，我们一般不在这些表之间建立物理的外键关系。
在有的互联网项目中，表的外键是不推荐使用的，除了外键会导致数据的插入、更新的性能变差之外，还要考虑的是分库分表会导致外键根本无法发挥作用。
因此，如果大家所在的项目也恰好要求不使用外键的话，那么采用聚合的划分可以满足这个要求。
当然聚合内部实体类之间的外键关系默认仍然是存在的，而且EF Core也没有提供默认取消外键关系的方法，即使采用分库分表，我们一般也要求紧密关联的数据放到一个数据库、同一个表中，因此聚合内的外键关系默认启用即可。
如果大家所在的项目要求完全禁用外键，那么可以在每次执行数据库迁移后，执行单独的删除外键的脚本。
在前后端分离的项目中，有可能一个操作就需要前端页面向后台服务器发送多个请求，这不仅会给前端的开发带来麻烦，而且也可能带来不好的用户体验；
有时候前端会对后端接口的返回数据进行微调，这些工作如果前端等待后端开发人员来完成，就可能会严重影响项目的进度。
因此本书作者建议在前端项目中引入Node.js作为中间层，这样前端开发人员就可以在这个中间层中进行请求的合并及增加额外的数据处理，这样不仅能够加快项目的开发进度，而且能够提升前端的性能。