Glass (11) [Avatar] Offline
#1
I read chapter 1.4.1 several times to ensure I wasn't missing anything but how exactly do you decouple your domain (including repository) from a Windows service. My domain is quite simple and involves only a handful of entities (tables) as the application is mainly read-only. I understand that decoupling your data access requires either injecting an abstract class or interface.

Currently, my project solution is structured like so.

Client
Common (includes domain and data access)
Service

If you take a look at http://pastebin.com/qYwpWBYN you will see a simple scenario of where my domain is leaking into my Service project (specifically the `Parser` class). Both Common and Service projects have a direct dependency on Common. Common does not have a dependency on anything. I supposed you could think as the dependency graph as the following.

Client --> Common <-- Service

Needless to say my domain objects are leaking into my Service project. It does say you can extract an from your domain domain object if your stakeholders demand it. The way the text is currently written makes it seem that doing so is rare and not necessary to have modular code. Am I correct in my assumption?

After writing this question it struck me. Is it even worth abstracting your domain? Seems say if you were going from say SQL Server to Oracle that your domain would remain intact and only your data access code would change.

Thanks, Mark.
mark.seemann (383) [Avatar] Offline
#2
Re: Decoupling domain
It seems to me that you have your dependencies inverted. You generally don't want to protect your domain model from leaking through, you want to protect the domain from leaky abstractions from all the other dependencies. In general, the model is the core of the application.

The code you pasted has no abstractions (interfaces or abstract classes), so you can't isolate one module from the other.

Another thing that strikes me is that you'd need to separate the the domain model from the data access code - otherwise you'd have a tight coupling there.
Glass (11) [Avatar] Offline
#3
Re: Decoupling domain
I'm not quite following how I have my dependencies inverted. With your second sentence are you basically saying that you should only protect your domain from data access code?

And you're correct. The code I pasted purposely doesn't contain any abstractions for the sake of brevity. The main purpose of the code snippet was to see if abstracting every domain model was worth it for purposes of it (domain) not leaking all over.

Some of these terms are pretty new to me, and I appreciate your time.
mark.seemann (383) [Avatar] Offline
#4
Re: Decoupling domain
Yes, the domain should be protected from data access code (and UI code, and logging code, and DI Containers, and whatever other Generic Subdomains you might throw at it).

Since DI totally depends on abstractions, it doesn't make much sense to try to discuss code examples where all classes are concrete. The loose coupling sits in the seams, not in the classes themselves, so I can't really say anything one way or the other based on your code snippets.

Are you basing your questions on chapter 1, or did you read the entire book? I'm just asking because I'd like to know if the entire book is unclear.

However, I wouldn't expect anyone to be able to successfully design a loosely coupled application based only on chapter 1. That was never the goal...
Glass (11) [Avatar] Offline
#5
Re: Decoupling domain
I did read the book in its entirety about 2 months ago (minus the container specific chapters except Castle Windsor). However, it seems pretty obvious I missed some important pieces. I'm going to read it again.

Thank you.
Glass (11) [Avatar] Offline
#6
Re: Decoupling domain
I've re-read the book up to chapter 10, where it starts being container specific. While it certainly cleared some of my confusion, my current confusion regarding my domain remains. I'm not sure why I'm stuggling with this one question as everything else you wrote about is quite clear.

Find my updated sample here (http://pastebin.com/Nc1babqX). All abstractions have been added minus domain object `Foobar`. So perhaps a better question is, how do decouple creating new instances of your domain classes? I mean, you're going to have to `new` up your domain POCO's somewhere in the code before you can insert them in the database. In my case I `new` up my domain object once it's parsed. Since your domain POCO's should be ORM agnostic does it even matter?
mark.seemann (383) [Avatar] Offline
#7
Re: Decoupling domain
That code looks pretty much okay to me, although I would still strongly recommend splitting the domain model away from the data access implementation.

As I understand it, your Service layer consumes the Domain Model. It's a very common thing to do - letting the boundary layer consume and orchestrate the Domain Model. If you really want to decouple those two, you'll need to introduce an IFooBar interface to hide the FooBar class behind, but normally there's no point.

In the vast majority of cases, the Domain Model is the important asset that we wish to protect against leaky abstractions, so I see no problem in creating new FooBar instances from within ObjectParser. FooBar is not a Service, but an Entity, so not normally something we address through DI.

You may find this SO answer helpful: http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-object/4836790#4836790
Glass (11) [Avatar] Offline
#8
Re: Decoupling domain
Thank you very much, Mark.

Your time is appreciated. And that SO link is definitely helpful.

smilie