June 2009 - DDD on the Web

This post is over a week in the making. I attended AltNetBeers #9 last week in London which is making a quick rise in my list of top developer-related events, big or small. And that’s not just because I got one of the best compliments ever from someone who claims his non-IT friend reads a single IT-related blog (take that, Hanselman!). Anyway, it’s nice to know I’m reaching my target audience. The event was not altogether removed from what Sebastien outlined at the one I attended last year which shows a degree of vision to which I only aspire. We spent a couple of hours talking on a topic of choice (as voted by attendees), then socialized until the place closed down at the unreasonable hour of 11pm. I’m told much merriment ensued afterward but, after posing for a picture , I made my way back to the hotel. The topic at hand, and I’m paraphrasing: How do we become better developers today, and how do we create them tomorrow? Nice and subjectively vague, just how I like my open spaces. The runner up topic, brownfield applications, seemed suspiciously planted so I threw my weight behind the one we eventually chose. Kinda concerned at how often this image is relevant to my posts Conversation ran the usual gamut from apprenticeship programs...

Once again, Gojko Adzic comes with an excellent post : Improving performance and scalability with DDD . Aggregates are often a bit underused in DDD because they’re difficult to grasp. They’re often seen as a solution to a technical problem. Gojko shows here how to understand them at a domain level. This post gives a clear vision of the role of Aggregates in DDD by placing it in the context of distributed environments. You should read it ! Read More...

From the beginning of my current project we have been working under some horrible constraints, many imposed by legacy systems, many by late decisions that would have speeded things immensely if made earlier, and many imposed by decisions that are outside of my control. This lead us early on to make decisions on architecture that eliminated any possibility of using DDD heavily, and as I mentioned in my original post about this project it is also essentially a glorified CRUD system - we read data from databases, we modify it a bit, and we put it back again. What We Are Doing – Command Query Separation The first architectural choice that I made, and in hindsight got accepted with relative ease, was to employ CQS to simplify the system. Earlier projects had suffered quite badly from being abstractions of legacy systems with new functionality bolted on. As far as possible I wanted to eliminate this problem from our project, as I was all too aware that this was an easy trap for the team to fall into, and would burn a lot of development time very fast. To make the system simpler I chose to separate our query mechanisms from the "domain" type stuff, our commands and data writing/updating code. CQS is a pretty simple concept. One...

As you may have noticed, I’ve been covering a bit about concurrency on this blog lately, and for good reason.  Between Axum, Erlang, Scala and F#, there is a lot to explore with actor model concurrency, task based concurrency, data parallel applications and so on.  In the next couple of months, I have some talks coming up on concurrency and in particular with F#.  I’ve been covering a bit of that with F# and mailbox processing, but I wanted to step back a bit into the asynchronous workflows and hitting against a well known API.  In this case, let’s walk through a simple example of using the Twitter HTTP API to get a user timeline using F# asynchronous workflows.  Best of all, I’ve done all of the above code without ever once opening up Visual Studio and instead using the power of a simple text editor and F# interactive, I’m able to be quite productive.  It certainly makes me rethink my utter dependence on certain tools… Give me some tweets… eventually, when you get around to it In order to get started, we need some helpers when dealing with LINQ to XML.  In a previous post , I talked about the need for such a thing due to the lack of implicit operator support in F#.  We can use the same operator...

I attended JP's Nothin But .Net course ( http://www.jpboodhoo.com/training.oo ) last week and I wanted to share my perspective with anyone who might be considering the course. I really enjoyed the experience and I'd happily recommend the course . . . to the right people. Rather than do the usual "I recommend this course because blah, blah, blah" I'd like to tell you why you shouldn't or wouldn't want to attend. If you make to the end of this post and still want to attend, I highly recommend you do as soon as possible. If you already have an incredibly strong understanding of the .Net Framework, TDD, BDD, DDD, or if you have a style/way of programming that is perfectly effective and satisfying for you then don't attend. If fact, if you're any good at teaching, you might wish to start your own course. If you are very comfortable with your life and your method of programming and you don't wish to be challenged then this would be a bad course for you. JP will challenge you to improve your coding skills and your life. Not your idea of a good time? Stay home. If you are very weak in .Net, especially if you are new to it, wait. Learn more about the framework, delegates, generics, and unit testing...

This is a recurring question on the DDD yahoo group . And there was a simple explanation during the ParisJug talk . DDD is not a silver bullet for all application development, it just helps to manage complexity when the complexity comes from the domain. No need for DDD when working on a technical application or a small application with few interactions. You could benefit from DDD when your application looks like the Cargo sample : Route containers based on transports availability Take cost and time into account Know where are the boats Organize loads and unloads Manage container storage (emit order of missions for employees on site) Provide container tracking and tracing to clients Transports can be late, manage it Transports can be canceled, manage it Contracts can be changed, destination can change Containers can be incorrectly routed even if emitted orders where correct, manage it. Manage taxes Manage time zones Manage currencies Manager constraints and local rules on dangerous containers contents In this kind of application, the complexity doesn’t come from an Xml web service or a database schema. Even without taking account any technical concern, it is complex ! So there is a simple rule of thumb to know if DDD could apply (independently...

This is one of those small things that is easy to forget. Usually when we use a for loop, we'll just incrment over an integer so that we can get a specific item out of some iteration. But you can do much more than that. My current project has a complicated scheduling component and I'm often working with a range of dates. I often need to do something with the days between two dates. I created a TimePeriod class that is created with a start and end date. public class TimePeriod { private readonly DateTime _start; private readonly DateTime _end; public TimePeriod(DateTime start, DateTime end) { _start = start; _end = end; } ... } Now what I need to do is iterate over all of the days that are between these two dates. I was struggling with this for a while, trying get a clean implementation. Then I remembered that the for loop could do this for me. Instead of using the standard i++ of the loop action, I add a day to the iteration variable. Now I can get every day between the start and end date. public IEnumerable<DateTime> DaysInPeriod() { for(var d = _start; d <= _end; d = d.AddDays(1)) { yield return d; } } Once I had this in place, I was able to put on some more convenience methods to cut down on some repetitive tasks...