I have spent the last few weeks enjoying learning about Clean Architecture and Domain Driven Design and I would now like to use it for a personal project to try it out. But I am having trouble with a few key concepts regarding modelling my domain space! I have spent some time thinking about this and looked for examples online but feel I might be thinking about this the wrong way. The situation I am trying to model is described below...
The purpose of my application is to build a set of xml files called 'components'. All of 'components' built form an overall 'build'. Each component contains a whole host of attributes, such as arguments, summaries etc.
So far I have decided that the attributes of the 'components' will be Value Objects and the 'component' itself will be an Entity (since it has a lifetime within the application). I also believe the 'build' as a whole should be an Entity as its lifetime would be the duration the components are instantiated and built etc. So the aspect of the model I am struggling with is how many aggregates should I have and what should the(ier) root(s) be? Should a 'component' be an Aggregate because they are often treated as a whole in terms of their construction? But then the build would also need to be an Aggregate which contains a list of associated Aggregates (i.e. the 'components'), is this ok?
Any guidance or material on this would be greatly appreciated!
The purpose of my application is to build a set of xml files called 'components'
I think you are approaching the problem from the wrong side. In DDD you should model the business rules first independent of infrastructure such as file formats. The aggregates should enforce those rules. But if transforming some data into xml files is really the purpose of your program, then DDD is total overkill and it would be better to write a script or similar to do the job.