Search This Blog

Tuesday, November 4, 2014

Next Version of C#

Watched this video  about the next version of C#.


We could use the code introspection features to validate our coding standards.  Also the nameof operator could be used in FluentNhibernate for mapping properties so when you rename your properties your mappings update.

Tuesday, April 8, 2014

CQRS Appendix

I finished the Appendix on CQRS in the book Implementing Domain Driven Design.

I really liked the appendix. It was written by a different author, and he provided very detailed code and explanations. There is even an example project on github.

I searched for my more information about the author and found a blog post where he mentioned Greg Young's Event Store. I didn't know this existed but it sounds pretty cool.

Monday, March 17, 2014

14 chapters down one appendix to go

I finished Chapter 14 on the Application of Implementing Domain Driven Design.

We have had the "What should go in a Application Service and what should go in a domain service" discussion here at work many times. At one point, the author claims I am going to clearly answer this question for you. I thought great I won't have to stress about that anymore. I feel like a broken record saying this but ... I was hoping he would give more details in his explanation because it still doesn't seem clear to me. What I got from what the book is that Application Services are for handling transactions and security. If you are doing more than creating an entity and adding it to a repository then you may have a "significant process" that needs to be modeled in the domain. He talked a little about Application Services that are for querying. I couldn't find any rules of thumb though about when your queries have too much business logic and should be domain services themselves. He did mention that sometimes you need to convert your application service into its own bounded context. I can think of one place in our code that might benefit from this idea.

There are no more chapters in the book. There is an appendix about CQRS written by someone else which I plan to read, but for the most part I am done with this book. I can't say I enjoyed reading it. I was really hoping it would answer a lot of questions for me, but I really don't think it did. I did some learn some things but not a whole lot. I guess the author's writing style just doesn't fit with how I learn. He probably knows a lot of stuff that can help me, but whatever reason I just didn't get that information from this book.

Tuesday, March 11, 2014

Bounded Context Integration

I finished Chapter 13 on Integrating Bounded Contexts of Implementing Domain Driven Design.

In our domain everything is jumbled together in one giant bounded context. Having never done what the author describes I found this chapter very interesting.

I liked the discussion about messaging. I had never thought about messages arriving out of order. I thought the author came up with a very simple solution to what could be a very complicated problem.

I also liked the discussion where he modeled a long running process as an entity and setup trackers to do automatic retries. I had to do something similar with a third party service our application integrates with. The code I wrote was very specific to the one area I was working on though. If you did this type of integration in multiple places in your application, then I could see that having more generic reusable components could be very helpful.

Sunday, February 9, 2014

Finished repository chapter

I finished Chapter 12 on Repositories of Implementing Domain Driven Design.

I thought the discussion he had on the performance benefits of Toplink was interesting. I remember having a similar discussion a while ago where we considering using stateless sessions for our readonly web services. This isn't quite as good as the Toplink design since even on our write operations we typically read data we don't intend to modify to do various types of validation.

I was little surprised he supports use case optimal queries which from what I can gather is using sql to create DTOs or value objects and returning them from your repositories. I would have thought he would only recommend that in cases of extreme performance problems. He did say if you are doing it a lot then it is probably a code smell.

He also has a section about Type hierarchies and how you should limit use of them. I tried implementing a Type hierarchy in NHibernate and it didn't go well for me. He had some good ideas about how to hide the types inside the aggregate and how to not let them leak out to be used by other aggregates.

I was also surprised he didn't give an example of how to test a repository with a mock. He did give an example of how to test with a real database and with a stub though.

Tuesday, February 4, 2014

The rules of aggregates

I finished Chapter 10 on Aggregates and Chapter 11 on Factories of Implementing Domain Driven Design.

I remember talking about Large Cluster Aggregates with one of my coworkers when we first started trying DDD. We didn't call them Large Cluster Aggregate at that time we just had two opposite ways we wanted to design our aggregates. We worried that if we didn't use large cluster aggregates then we would have an Anemic Domain Model. We felt like if we did use them then we would run into some bad transaction/performance problems. Erring on the side of caution we chose not to use them so I was happy the author also recommended not using them.

I also remember us discussing whether to reference everything by identity or by the entity. Even though we have a coding standard that says reference by entity I still think we reference by identity at least 50 percent of the time. I always preferred identity but I never had a really good argument of why. I think referencing by identity does make it more difficult to build up the data needed to generate a UI. For example a UI displaying a list of articles should probably display the author's name and not the ID of the author. When referencing by identity this usually means you need to query all the author's and then join them back with the articles in memory to create the DTOs needed for the UI.

The author talked with Eric Evans, and they came up with a good rule for when to be transactionally consistent and when to be eventually consistent. If it is the job of the person making the request to make the two aggregates consistent then be transactionally consistent. If it is someone else's job to make the two aggregates consistent then be eventually consistent. This mirror's what happens in real life and makes sense to me. When you get married your HR person does not instantly change your tax withholding while you stand at the altar. You change your tax withholding at some reasonable time in the future.

The author also mentions to not inject repositories or domain services into Aggregates. Even though the topic is heavily debated at my work we are currently not injecting repositories into Aggregates. We do in some cases though pass services into our aggregates using a Double Dispatch technique. Unfortunately the author does not give a lot of detail into why he recommends you don't pass repositories into Aggregates. I wish there was a book or pdf that had all the generally accepted good DDD practices and a short explanation of why it is a generally accepted good practice. Maybe things aren't that black and white though.

The one thing I took away from the factory chapter was that he recommended using factory methods instead of separate factory classes. I have never been a big fan of our factory classes since they seem to just initialize the properties on our classes and do very little work. I think mostly I just don't like calling a method with 10 parameters. Half the time you can't figure out what those parameters mean without drilling into the factory. What does that 5th parameter that is null represent? I guess the factory methods could reduce some of those parameters. I also like the idea of using the builder pattern instead of factory if you have a bunch of optional parameters.

Monday, January 20, 2014

Show me the code

I finished Chapter 8 on Domain Events and Chapter 9 on Modules of Implementing Domain Driven Design. I liked the author's explanation of how to integrate two different bounded contexts using events. He gave a couple different options like setting up a REST feed of events and also using a third party messaging tool. I thought both examples were clear and easy to follow.

He also mentioned you could use events to hook your domain to your application layer and also use events to hook up different components within your domain. He gave an example he called contrived for hooking the domain to the application layer. It was basically a method on an aggregate that did nothing but raise an event which was caught by an application service that added something to a repository. It wasn't very helpful to understanding the concept he was trying to explain. Also there were no examples of how to use events inside your domain model. I thought I might get more information by downloading his source code, but I checked the java and .net versions and their were no examples there either.

I am also reading the Big Nerd Ranch iOS book. I was struck the other day by the difference in the author's styles. In IDD the author starts with a lot of details about what he is trying to explain then sometimes follows that with a snippet of code that may or may not help explain his theory. By contrast the Big Nerd Ranch book starts out with a bunch of code that you can compile and run. The Big Nerd Ranch author warns you that you probably won't understand what you are typing but urges you to type it anyway. Once you have a working example they then go back and explain what you typed. I like the Big Nerd Ranch style much better. I can digest the theory a lot better if I can look at the actual code. I think in some ways I read code better than I read English.

The modules chapter was pretty thin. The one thing I got excited about was when he said not to create a separate folder for each component like factories, repositories, value objects, etc ... We have this Services folder that I don't like because it groups all these random services together that are in no way related. Later in the chapter he did say you could have a separate model and services folder if you treat your services like a thin layer between the domain and application. I am guessing though he still wouldn't recommend dumping all the services in there. Instead you still need to break that folder up into submodules if you have more than handful of services.

Thursday, January 2, 2014