Q: D3 vs TDD best practices Which one offers more advantages for a large software, say like Photoshop?
Also by TDD I don't mean just unit tests, because you can use unit tests in D3 too, just not the same way TDD does.
D3: Design Driven Development 
TDD: Test-Driven Development

A: In my opinion when you write tests first (in TDD), you are designing the system. If we can not write tests first, it shows there is ambiguity in requirement. We can write story before test and use it as specification known Test As Specification. After passing the tests, we can use tests as document known Test As Document. When new developers added to project they can use these tests for learning the system business.
In DDD you just use story for creating relationships between objects. What is important in DDD is that you should focus only on domain. For example when writing domain business logic, you should not be worried about saving entities on the database. In short, you should not think about anything outside the domains when writing business logic.

A: TDD is neither bottom-up nor writing tests before coding.
TDD is about using tests to drive the development with the goal that the code is tested before delivery.
It begins with ensuring that the user requirements are written in a form that makes automated user acceptance tests possible. It continues through integration and functional testing down to unit testing. Unit testing does form the lion's share in the end.
The reason why tests should be written first is because when a solution to a problem is considered (designed), you automatically have expectations what the solution should do. Any expectation can be expressed as a test, so why not immediately document the expectation and at the same time have an automated test for it to ensure the solution achieves that goal?

A: I also don't think they're mutually exclusive I think you can use TDD to get to DDD.

A: DDD = Domain Driven Design
TDD means that before you write any unit of behavior you have a test for this behavior and only this behavior.  Only after these tests fail do you implement the behavior.  In every incarnation that I've seen TDD has been on the level of a method or class - maybe a couple classes working together.  The end result is that you get highly testable and hence very loosely coupled code.  Ultimately though TDD is about creating code that can be tested.
DDD is a far more abstract philosophy and set of design patterns that addresses how to design a large, scalable, and maintainable system.  Ultimately DDD is about creating a code eco-system that implicitly or explicitly captures important bits of domain knowledge.
So you see, they are certainly not mutually exclusive.  Pretty much everyone I know who is knowledgeable in DDD is also a hard-core TDD enthusiast.
