DDD Step By Step
A Practical Guide to Domain Driven Design

May 2009 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • Top 10 Reasons to Attend DevTeach Vancouver by james.kovacs

    DevTeach is my favourite conference of the year and it’s happening again in Vancouver on June 8-12, 2009. No, it’s not my favourite conference because I’m one of the Tech Chairs . It’s the other way around. I’m a Tech Chair because DevTeach is my favourite conference. For the curious, Tech Chairs do not receive an honorarium or other compensation. We do it because we love DevTeach and the community it brings together. Here are my Top 10 Reasons to attend DevTeach Vancouver. It’s got a dedicated Agile Track , baby! 18 sessions of agile goodness. The Agile Track has more TLAs than any other track, including TDD, BDD, DDD, ORM, IoC, and DSL! Internationally renowned speakers, including Oren Eini (aka Ayende Rahien), David Laribee, Michael Stiefel, Greg Young, Eric Renaud, Francois Tanguay, Claudio Lassala, Hamilton Verissimo, Owen Rogers, Donald Belcham, and me. And that’s just the Agile Track! More IoC than you can shake a stick at with sessions by Oren Eini (current maintainer of Castle Windsor), Hamilton Verissimo (creator of Castle Windsor and Microsoft PM on MEF), and me. (I feel so outclassed in that line-up.) 1-day pre-conference session on Agile Development with IoC and ORM with James Kovacs and Oren Eini. Register now! ($399...

  • See you at DDD South West by Jimmy

    I'm heading down to Taunton this Saturday for DDD Sout West ( www.dddsouthwest.com ) where I will have a session (see below). Pop in and say hello if you will be there. Hope to see you there. Read More...

  • F# Actors Revisited by Matthew.Podwysocki

    In the previous post , I covered briefly about the actor model in F#.  This style of concurrency, using asynchronous message passing and a shared-nothing approach through the use of mailboxes is a pretty powerful mechanism for achieving scalability.  With a shared-nothing approach, we can remove the need for such concurrency primitives such as locks.  Taking cues from Erlang, F# has the capabilities as well through the use of the MailboxProcessor class.  In this post, let’s walk through a canonical example and explain some of the design patterns around this. Mailboxes, Etc Before we begin, let’s make sure we have some of the basics down.  As I stated above, the approach here is that inter-agent communication is accomplished through a shared-nothing asynchronous message passing system.  Each of these agents have a mailbox, which is nothing more than a queue of messages sent by other processes.  These messages are then retrieved via either a scan or receive approach, depending if you wish to continue receiving messages.  To determine which message we received, we do basic pattern matching against our given message types and decide how we want to handle it.   To continue processing, we...

  • Commercial Suicide - Integration at the Service Level by Jak Charlton

    In my previous post I described the problems with trying to integrate your organisation at the database level , and the fallacies surrounding the idea of the One True Authority Database. I also alluded to this being a problem with services too. When you try to create a monolithic and authoritarian database that knows all, sees all, and brings everything into a single coherrent whole, you are heading down a slippery slope. Different applications have different requirements, and even within the same job role, the meaning of Customer can have a totally different meaning in two different contexts. I also argued that data has no value without context, and the context is the application that is meeting the business requirements, be these user interaction, system interaction, or reporting. SOA to the Rescue! I'm not arguing without ample evidence behind me here - the idea of integration at a database level was one that was well discredited many years ago. I grant you many organisations haven't got the message yet, and that many vested interests still keep trying to make the magic solution work, but fundamentally a long time back we in IT recognised that the One True Authority Database (OTADB) was a "bad thing" - and this...

  • Next Europe VAN - 1st June 2009 - Questions for Udi Dahan by Colin Jack

    Udi Dahan has been kind enough to agree to do the next Europe VAN and suggested that we all put forward our questions for him to answer. Its a great chance to ask him about DDD/SOA/CQS/messaging/ NServiceBus , or any other topic, so if you have any questions post them here or on the associated thread on the DDD / ALT.NET forums. Jan and I will aggregate the questions (and add our own!) and then submit them to Udi by the 25th May so ensure you've submitted them before then. Read More...

  • DDD - Microsoft Guidance by Yves Goeleven

    According to Paul Gielens , Microsoft is working to include technical DDD guidance into their next version of the Application Architecture Guide... I'm really looking forward to this ... Read More...

  • Interoperability by Jimmy

    In a few weeks I will be giving presentation about interoperability with WCF on DDD South West. It will be my first presentation on an event bigger than a user group meeting. If any of you will be on the event please come over to say hello. Also, I'm open to any suggestions and ideas on what you would like to see. Read More...

  • Early morning train by Jimmy

    Finally I have some spare time to actually sit down and write something ant even this only because I'm in the 6.48 in the morning train for London and apart of sleeping I have nothing better to do. It's been a while since my last post and I think I lost my blogging commitment somewhere. Assuming I ever had any. Anyway, that is not really relevant to what I wanted to write about. Stroud What is your first thought when you thing about developers' communities? Mine always was something around free t-shirts and having a fun. I still think the same way but cool and free t-shirts were recently replaced by hard work. Luckily fun is still there. Why hard work then? Well, if you are not from my area you may not know but I've started a user group and it's a whole lot of work. I've never suspected that there are so many things to do and to manage but even if I would I will do that again. It's a great experience and even better satisfaction when you see people coming over for a meeting. Kemble It's taking a while to write that, maybe because I'm working on my DDD presentation in the same time. Back to the user group thing. Everything really started over a year go when I thought about this for a very first time...

  • POTM: Breaking Free from HttpContext by cramsay

    The System.Web.HttpContext class is a real heavyweight of the .NET Framework. It holds a wealth of information on the current server context, from the details of the current user request to a host of details about the server. It's accessible from the HttpContext.Current static property, which means you can get hold of this information at and point in your code. Whether this is a strength or a weakness depends on your point of view, but consider the following code: public class AuthenticationService { public IRepository Repository { get; set; } public void Login(string username, string password) { User user = Repository.FindByLogin(username, password); HttpContext.Current.Session["currentuserid"] = user.Id; } } This type of code is probably pretty widespread; separate authentication code into a separate class. The problem with this type of code comes when you want to test it. Consider this test snippet: [TestMethod] public void Should_Retrieve_User_From_Repo() { _authService.Login(username, password); _repo.AssertWasCalled(x => x.FindByLogin(username, password); } This will fail hard, because when your test runs, you don't have a current HttpContext available to work with. In theory, you could fire up a webserver...

  • Breaking Free from HttpContext by cramsay

    The System.Web.HttpContext class is a real heavyweight of the .NET Framework. It holds a wealth of information on the current server context, from the details of the current user request to a host of details about the server. It's accessible from the HttpContext.Current static property, which means you can get hold of this information at and point in your code. Whether this is a strength or a weakness depends on your point of view, but consider the following code: public class AuthenticationService { public IRepository Repository { get; set; } public void Login(string username, string password) { User user = Repository.FindByLogin(username, password); HttpContext.Current.Session["currentuserid"] = user.Id; } } This type of code is probably pretty widespread; separate authentication code into a separate class. The problem with this type of code comes when you want to test it. Consider this test snippet: [TestMethod] public void Should_Retrieve_User_From_Repo() { _authService.Login(username, password); _repo.AssertWasCalled(x => x.FindByLogin(username, password); } This will fail hard, because within the context of your test, you don't have a current HttpContext available to work with. In theory, you could fire up...