Subscribe: Ian Nelson
Added By: Feedage Forager Feedage Grade B rated
Language: English
architectural concepts  architectural  dddnorth  events  find  handle  ian  icooper  information  layers  opportunity  sessions  things  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Ian Nelson

Ian Nelson Systems

Freelance Professional Software Developer with 16 years’ experience across the full product lifecycle. Based in York / Leeds, Yorkshire, UK. Available for .NET Contractor Roles.

Last Build Date: Thu, 27 Oct 2016 05:07:25 GMT


DDDNorth 2014 Review

Wed, 09 Mar 2011 09:03:00 GMT

I had no excuse for not attending DDDNorth this year, as it was held at Leeds University, a relatively short drive from home. Not that I'd be looking for an excuse - these free events are always superbly organised and provide a valuable opportunity to see sessions from a wide range of speakers without having to take time off work. It's no wonder the tickets are always snapped up so quickly. As a contractor, I also appreciate the opportunity that DDDNorth affords me to catch up with so many friends and colleagues that I've worked with over the years, and it was great to see so many familiar faces. With five slots during the day each offering five concurrent sessions there were plenty of difficult choices to be made. In general, I tried to attend sessions offering information I didn't think I would be able to get from books, blogs or PluralSight - stories from the trenches and architectural concepts rather than deep dives on specific technologies. The first session I attended was "So You Want To Be A Tech Lead - 10 Things You Need To Do To Succeed" by Joel Hammond-Turner (@rammesses). I was delighted to find that the eponymous ten things were not airy-fairy woolly soft-skill type things, but in fact consisted of ten topics backed by a whole bunch of concrete real-world actionable suggestions. These ranged from large architectural tasks (use NuGet obsessively for all internal dependencies, set up automated release management with Octopus, etc) to the little things that can make a difference (be willing to take your headphones off, read and share The Morning Brew, add photographs to Personas..) Next I saw "Not Just Layers! What Can Pipelines and Events Do For You?", presented by DDD circuit regular Ian Cooper (@icooper). This was the most technical session that I saw, and required some serious concentration. Ian started his presentation with some slides that explained the theoretical background behind the architectural concepts he was introducing. These were beautiful and densely packed with information, and I plan to review them at my leisure! He then fired up Visual Studio and demonstrated some C# implementations of the patterns previously described. Kudos to Ian for creating a successful presentation on a fairly dry architectural topic - inevitably it could only scratch the surface but has whetted my appetite to venture beyond the typical layering approach when considering candidate software architectures. Two eyes and two ears is not enough kit for 'Not Just Layers', @DDDNorth @ICooper— Mark Dickinson (@tuganetmark) October 18, 2014 But nothing worked. Every time I loaded an Order, the Order.Address object was reset back to its default instead of containing the data loaded from the database. This is quite frustrating and as yet I haven’t been able to find a workaround, other than to abandon my plans to perform object initialization in the domain model and instead handle it in the service layer, with all the resultant null-checking code that will ensue. While trying to find a solution, I did stumble across this comment from Rowan Miller that “More flexibility in how we interact with classes is a common ask for EF and our team is looking at how we can support this at the moment.” Are we asking for flexibility? I thought we were just asking for the persistence ignorance that had long been promised. Despite these issues, in three short days I had gone from knowing next to nothing about Entity Framework 4 Code first, to using it to perform almost all of the data access required by a small application. In the fourth part of this series I’ll consider some of the additional features and application requirements that I would expect an ORM to handle, and see how EF meets the challenge.[...]