Random thoughts on Domain Services

I finished Chapter 7 on Domain Services of Implementing Domain Driven Design. In this chapter the author mentioned it was a good rule of thumb to not pass repositories into entities. We follow this practice at work as well. Someone recently challenged me on this practice, and I didn't have a great reason to give to them on why we chose to do this. I thought it had something to do with persistence ignorance, but I couldn't remember exactly why we instituted the practice. Unfortunately the author really doesn't get into the reason why you shouldn't do this either.

The author also recommended to not put a separate interface on your domain services unless you have know you are going to have to vary the logic of the service with different implementations for different customers. We also follow this practice, but I feel like it would be easier to mock the domain service when testing an application service if the domain service had a separate interface. The author doesn't explain how he tests his application services.

The author did call out that there shouldn't be any business logic in the application services. He didn't really get into how he defined business logic though. We frequently get into discussions at work about whether some code should be in the domain or just in the application layer. The discussion usually ends up at is this code business logic or not. I think if we have AC around it and we would want multiple UIs (desktop and mobile) to follow this behavior then it is probably business logic.

Automating ExtJs 3 to ExtJs 4 code conversion

I was thinking one of these tools might help me write a script to automate code conversion between ExtJs 3 and ExtJs 4.  I don't have time to try it right now but wanted to save these links in case that job ever lands on my plate.

http://jsshaper.org/

https://github.com/ajaxorg/treehugger

Video about how youtube works

These guys have a really good attitude about solving a really hard problem.

http://feedly.com/e/mI7rXNrQ

Article about Google building support for Mobile Chrome Apps

This could make writing apps that run everywhere easier.

http://feedly.com/e/-kuNBX3M

Passing in more than needed

I finished Chapter 6 of Implementing Domain Driven Design. I am still not enjoying this book even though I will force myself to continue. Again the author promised many times he was going to reveal this really important bit of knowledge of how we are overusing entities and should be using value objects more in the domain. I thought he was going to talk about the return values from domain services and how those things are really important pieces of the UL. Instead his examples were more about avoiding primitive obsession. It is important information but I guess it was just not what I was hoping for. The next chapter is about Domain Services so maybe the information I am looking for is in there.

He did make one point I found interesting. He said that when you design a method definition you shouldn't pass in the whole entity if all you need is one value object off that entity. I have been doing the opposite lately. I try to make the client of the method as dumb as possible and put the logic of what needs to happen in the method doing the work. I find this makes reading my code easier. His point though was that you can't be sure that your method is side effect free if you pass in the whole entity. Also he said it makes testing harder to pass in the whole entity because you have to setup more data to pass to your method. I agree with both of his points. I am not sure I am ready to change my style yet, but the balance of pros and cons has definitely been shifted.