I suggest keeping a good high level desgin of the domains and packages and their connection with each other.
As for specific class documentation and tools, I don't think those are neccessarily an important requirement especially if you are maintining this in a small team or by yourself. The most important aspect is writing good clean, abstract code. If you spend half your time worrying about external documentation then you will be spending half your time not thinking about the code.
In saying this I think re-evaluating high level design concepts can help you keep a level head in writing the code. By high level I just mean not writing down every class, or every method. I would consider instead how groups of classes or components interact, what conceptual layering you have, and the interfaces between those layers/components.
So, in summary to keep track of code and help maintain abstraction, I would follow these steps:
1) Continual review and design of high level concepts using an UML approach or even just boxes and lines.
2) Using TDD on each package to help each package maintain extendable loose coupling code.
3) Some code documentation wher needed but not to get too overly fixated on this as it is more important to try and get your code self explanatory.
4) Constant refactoring of your code if you notice "during writing" that a high dependancy on other modues exist. Try not to leave code in a TODO state if you can help it just because you are under pressure to get it done. This can often lead down the start of messy code.