Wired review of a treadmill desk

I really want to try this:

http://feedly.com/k/18Zkn88

Pair programming would definitely not work unless they make tandem models. :)

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.

Domain Services are part of the UL?

I finished Chapter 5 of Implementing Domain Driven Design. I wanted to poke my eyes out while he was describing how to handle an id, but I really enjoyed the part where he started talking about how we would model a User. I liked that he talked through how he made each design decision and what other alternatives were considered. It was a pretty simple example, but I think he was able to pack in a lot of good tips.

One thing I thought was interesting was how he decided to include his DomainService in the UL. Sometimes I see really generically named services called <AggregateName>Service where AggregateName could be any one of the Aggregate Roots in our domain. Usually those services are catch all bucket for a whole list of very loosely related methods. I think if the DomainService's name were part of the UL then people would probably name it something more specific. I also wonder if having a specific name would reduce the number of things the service does down to one thing. Hopefully having each service have one responsibility would make these classes a lot easier to understand and maintain.

At the end of the chapter the author starts talking about validation. I remember our team having the hardest time figuring out how to do validation that requires a UnitOfWork. He didn't really talk about that problem much other than mentioning you could use a DomainService or use events. Oh well maybe he talks more about it later in the book.

Still flying up in the trees

The book I am reading Implementing Domain Driven Design gives this metaphor of flying in airplane viewing your childhood home and seeing something you are very familiar with at a detailed level from a high level so as to gain a new perspective. My hope after hearing that was that the author was going to eventually switch gears and explain things at a detail level instead of just giving the high level view that the book opens with. I am half way through Chapter 4 and I still feel like I am flying high waiting to see how the theory is applied to reality. I wish the author would explicitly tell the reader when they shift gears. For all I know he has already shifted I am just too clueless to consider the new style to be the detailed view.

I think the book definitely has useful information. I am getting the feeling though it is not the book I was thinking it was going to be. I was hoping for a book like "Domain Driven Design Practical Example Explained Step by Step". I am still missing how to take the theory and translate it to real code.

One interesting thing I read was about the Hexagonal Architecture. It is alternative to a layered architecture that allows multiple entry ports into the application. Our architecture definitely allows multiple entry points. Our thinking was that each major system would have its own entry point and that would allow us to change the internals of the domain but keep the entry point backwards compatible so as to not break those major systems with each domain change. Looking back now I am not sure that is really any better than having one versioned public API where systems that we couldn't upgrade could still remain on the old version of the API. The other main reason for this decision was that we could easily format the information in a way that each system needed so that the client code calling our API could be simpler. At least for our UI code I think this decision was helpful.

The author warns against business logic leaking out into the different ports. We definitely screwed that part up. Many of the stories I am work on now involve removing the business logic out of the port, putting it back into the domain, wrapping it with tests, and documenting the AC. Most of this business logic is how queries should work not commands. I think are application is definitely complex enough to merit the CQRS architecture described in the book. Separating out the queries would reduce some of the dependencies but not all of them. We still have cross aggregate validation to handle. Maybe he describes the solution for that later in the chapter.

Anyways I am going to keep reading. Hopefully I will glean something useful. I am still holding out for the DDD book that is mostly code with some explanations on why they made certain decisions.

Can your domain expert understand your test?

I started reading Implementing Domain Driven Design recently. I am happy there is a new DDD book. Even though I have read the original book multiple times I still feel like I am messing up some of the most important concepts. Vernon mentions in his new book that many people feel the way I do and he names our level of DDD practice "DDD-Lite". I am hoping reading his book will help me transition to a deeper level of understanding of DDD. If I learn something I find interesting I will try to post it here. Below is my first submission.

In Chapter 1, Vernon suggests that your domain expert should be able to read your first test that you create to define the new behavior you are adding to your domain model. I like this idea, because I think it will give you a good way to measure whether you really are creating a ubiquitous language and using it to design your code. If the domain expert can't understand your first test then your code is probably too complicated and you may not be getting the full benefit of DDD.

At work we create XML based tests that get translated into code. Part of the reason for creating the XML based tests was so our domain experts could read them. I think I like Vernon's solution better to this problem though. I like his solution better because our XML based solution allows us to write domain code that doesn't match the domain experts understanding of the problem and still show them domain tests that makes them think we understand the problem. The XML based solution is kind of like a cheat that covers up the real problem that our domain code is too complicated.

TechCrunch article about streaming any app for any OS through Javascript?

With New Service, Any Device Could Run Almost Any Program From Anywhere | TechCrunch:

Seems too crazy to work but stranger things have happened.