I am a beginner in DDD and would like to understand if it is a bad practice to try to populate a single aggregate root from multiple database ?
I am trying to design a system where all the properties of an aggregate root are being populated from one database except the name. The name happens to be in a different database and needs to be populated in the aggregate root so that it can be used.
TIA
Short answer: yes, it's a bad practice (or not even a practice).
As Martin Fowler expresses:
A DDD aggregate is a cluster of domain objects that can be treated as a single unit
One of the consequences of this statement is that aggregates need to be stored transactionally. The aggregate code will ensure its state consistency in memory, but if you cannot enforce that consistency in the database, you will have problems.
Having an aggregate stored in multiple databases means that you either won't be able to store them transactionally (which you shouldn't do) or that you'll have use distributed transactions (which you shouldn't do either ideally).
Regarding your specific problem, either your aggregate is wrong or your database design is wrong.
To see if your aggregate is wrong, consider why you need that Name property in that aggregate? It should be there only if it needs to change transactionally with the rest of the aggregate or the aggregate needs it to perform its business logic.
If the aggregate is correct, then move the Name property to the same database (and most likely same table) than the rest of the aggregate. If for some reason you need the Name in that other database in order to be available for some queries, maintain it with eventual consistency (when the Name changes in the aggregate, publish en event and subscribe to it to update the query database).
I am a beginner in DDD and would like to understand if it is a bad practice to try to populate a single aggregate root from multiple database ?
Yes. The happy path isn't the expensive one.
Reads aren't necessarily an issue; if all you are doing is producing a report, pulling data from multiple sources is fine (although we of course recognize that those sources might not be "consistent" with each other.
But trying to manage writes with two databases, it becomes difficult to ensure the integrity of your data when things start going wrong - a crash in the middle of your update does not leave your data in a healthy state.
The good news? If the data is already spread across two databases, it is likely that you have two aggregates to model, rather than one. It is perfectly normal to take some concept like "customer" and share it among multiple aggregates.
Once you've got your aggregate boundaries correct, you can arrange the aggregates among your databases in any way that makes sense; each modification in the model updates one database per transaction, and the business invariant is maintained.
Mauro Servienti's talk All Our Aggregates Are Wrong may be a useful starting point.
