一个人开发怎么来都可以，所谓规范更多的是用来解决多人开发的问题的。从多人协作的角度来看，两项目耦合同一个数据库就是不好的设计，因为这意味着 A 系统的开发者修改公用表的逻辑的时候需要去评估 B 系统是如何使用这张表的。解决这种耦合方法就是去划分领域，如果 AB 都是一个领域的，那么没必要划分成两个项目。如果 AB 领域不同，那么公用表是属于哪个领域的呢？是否要引入第三个领域 C 去做这一块逻辑？一般而言哪个系统写这张表就归谁，其他系统通过接口访问即可。不太理解你为什么要选择一种既不是单体又不是微服务的架构。你应该考虑的不是将 dao 变成公用的然后“复制”成两份给两个项目使用，而是该考虑这两个系统是否有独立部署运维的需求，如果有，考虑微服务，如果没有，合并成一个真的单体。
架构方面的书可以看《凤凰架构》，批判性的了解一下 DDD 。设计模式随便找些网站都能看到，但是关键是知道什么是设计模式。为什么这么多人用设计模式用的这么生硬，越写反而代码越难看？因为他们不理解设计模式只是在特定场景下的由一系列重构组合而成的解决方案。从这方面而言《重构》是一本好书，你可以注意到书中介绍的重构方法是极其的简单，并且部分方法之间是互相冲突的。这揭露出抽象化和反抽象化都可以是一种好的重构，重构没有银弹。之后你再去看那些设计模式，你就可以去推导，他们是由哪些重构组成的，其中各个重构的效果是什么，当前你需要哪些效果，如何去掉那些你不需要的重构。这样在解决问题的时候就不需要去硬套设计模式而引入一系列你还不需要重构导致代码笨重，产生过度(早)优化的问题。如何去应用 DDD 也如此思路。