Last post Jul 16, 2014 02:48 AM by Mikesdotnetting
Jul 15, 2014 10:23 PM|Alex_808|LINK
I'm a beginner trying to grasp the important concepts of "Onion Architecture" and had a specific question I was asking myself after reading an article. Look at the Domain in the architecture showed in the image below:
My question is what is the practicality of separating the Domain.Entities and Domain.Interfaces in two separate projects instead of having one Domain project with a entities and Interfaces folder? I know this can really be application specific (and may not
be relevant to onion architecture) but is it really a big deal in most scenarios to want to make a change on the interfaces of the domain entities without wanting to rebuild the domain entities or vice versa? And I really don't see a lot of scenarios
where you would want to re-use one project in another application without the other.. I have trouble seeing the benefits of that domain separation.. What am I missing?
And if you know any good simple examples of onion architecture do share :)
Thanks for the help!
Jul 16, 2014 02:48 AM|Mikesdotnetting|LINK
The stuff that you have in AppArch.Domain.Interfaces is in the wrong place in my view. Repositories are Data Access, not Domain. Also, generally you would not need interfaces for domain entities like Product or Category. Interfaces are like the disk tray
in a games console. They allow you to easily swap games without having to get a new console - so long as the new game disk conforms to the requirements set out by the tray's "contract" (which is inherent in its design e.g. diameter of x, thickness of y etc).
They are useful for pluggable components of your system like logging, emailing, data access etc, and allow you to swap implementations for mocks and fakes for testing - mainly to prevent actual mail services or logging systems from slowing tests down, or to
swap them if you need to change the actual component.
That hardly applies to the Product object, for example.