ddd
Domain model metrics turn "the split feels wrong" into something you can check: how many teams one change drags in, which arrows point the wrong way, why lines of code lie inside aggregates, and why you should sketch four models before picking one.
software-architecture
Pseudo-modularity looks like clean folders and rots underneath: a change in Products breaks Inventory tests and blocks three teams. Why noun-driven modules and a shared database create facade modularity, and what real module boundaries look like.
ddd
Module boundaries should come from simulation, not subdomain divination. An engineering method for DDD: optimise for modifiability, simulate realistic changes against candidate boundaries, prove the split with stable contracts, and explain it to the business.