0

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!

unknownpresense
  • 99
  • 9

1 Answers1

0

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.

Roman Weis
  • 347
  • 3
  • 8
  • Thanks for the response! Although I totally agree with your point, I am unfortunately under the restriction of merging my application into another much bigger DDD project in the not-so-distant future. The idea is to keep things consistent when merging, so I am forced into this coding style. In terms of my original post, I have decided to have the 'build' as the aggregate root and have the 'components' as sub-entities as it will fit my needs for the short term at least, with the review of potentially refactoring in the future (if required). – unknownpresense Mar 05 '19 at 18:38
  • I will mark this as the solution to my original post, as I feel my situation is fairly rare and producing a much simpler script like program would make more sense for the vast majority of users. – unknownpresense Mar 05 '19 at 18:43