It was fun while the riddle lasted, but I think I’ve got the solution.
And I like it))

I’ll write the proper post tomorrow after another one that I’ve delayed for too long..

I didn’t say that I like this approach to much to move it into the xLim 2 body of knowledge)) The bit feels nice and promising, but there has to be more to it.

One of the probable solutions to the problem is to integrate IoC and DDD together. This bit will be quite complex and resource-consuming (multiply ORM by IoC) but if it has the proper dev team with experience in both worlds then it could live with that.

DevExpress folks are trying to achieve that by implementing their reusable domain models. But this looks too heavy for me.

There should be some other simple and logically beautiful solution, but we just do not see it yet…

Good luck with your search and, please, do not hesitate to share your findings))

Best regards,
Rinat Abdullin

Every time the subject comes up across the blogosphere, however, it becomes pretty clear that people are choosing _between_ the two. They are either having good DDD, but are more tightly coupled, less abstracted, and have testing issues, or they are having good loose coupling, beter abstractions, and better testing, but are doing so at the cost of heading towards anemic domain models and Fowler-esque “transaction script”-style services.

Perhaps one of these days we’ll have both. I’m going to try to force this to happen on my next pet project just to see how things go. If I come up with anything interesting, I’ll be sure to mention it. :) In the meantime, I’ll be continuing my already-years-long search for a solution.

I knew that you would ask - see the last bullet-note in this article))

Simple brute-force solution is:
1) pull everything to the IAccount interface (including Save method, repeat for other BOs…)
2) register Account as IAccount and keep the existing Account registration as type (session will need it since it has to do some low-level work).
3) wrap the enumerator of the FireCollection with interface explicit implementation that returns IAccount (and do that for any other members that you need to use).

Then, you could ask IoC for IRepository{IAccount} or use IAccount to create new instances.

But I neither like this approach nor advice it - the objects will have to travel back from IAccount to Account inside the actual implementation, and that just does not feel right.

That’s why I haven’t mentioned this approach in the primary post.

Rinat