Yves Goeleven

Azure - a book you might want to preorder

Yves — Tue, 07 Jul 2009 19:53:51 GMT

When browsing amazon, I discovered the following book to pre-order on the topic of cloud computing on the azure platform

This book takes the effort to compare Azure with the main competive technologies such as Amazon S3, EC2, SimpleDB, the Google App Engine.

It will also focus on the challenges that developers and IT departments will face when moving to the platform.

Obviously it will also include the necessary explanation of the azure basics and some sample code

Should be an interesting read once it hits the shelves

]]>

Azure - IOC containers

Yves — Mon, 06 Jul 2009 21:49:23 GMT

Developing applications for the Azure platform isn't that different from regular application development, and if you don't pay attention it's going to be just a vile mess as any other app. Therefore my first advice to development on the platform is: use an ioc container to decouple the different layers and their dependencies. Granted, there is no data, but there are still a lot of things that you are dependent from...

But there are some caveats that you might need run into the first time you try to use an IOC container in your cloud project...

First of all, Azure is a partial trust environment by default. This means that any advanced use of reflection, such as ioc, is prohibited. In order to ensure that the role that you are deploying, role is cloud lingo for deployable unit, allows the use of an ioc container you need to configure it to support native code by setting the enableNativeCodeExecution to "true" in the ServiceDefinition.csdef file on the role tag of your choice.

Secondly you need to take into account that the assemblies have to be deployed to the cloud or development fabric, which is your local cloud emulation, before the types in it can be injection. By default visual studio will only copy the assemblies for which any type is actually referenced in the application assemblies. In case you would like to include any other assembly you will have to copy it to the yourapplication.csx\roles\Web\bin\ folder using a post build script, or make sure any type from the assembly is actually referenced. Personally I prefer the latter...

So that's it, just configure your container and your good to go...

]]>

Azure - My head in the cloud

Yves — Thu, 02 Jul 2009 22:02:48 GMT

You might have noticed it already over the past few months, the focus of my blog is starting to shift, even though I haven't blogged to much... Ever since Azure, Microsoft's cloud platform, has been announced at PDC last year, I have been playing with this new environment. I've been in a learning mode mostly as I try to figure out how to best build systems in an endlessly scalable world where some of the staple products, such as databases, don't exist or don't make sense.

One of the biggest enablers for learning more about this product has been a special interest group that I've set up internally at Capgemini. In this SIG quite a few of my colleagues teamed up with me to discuss various questions and play around with the bits as new CTP's came out. Some of the most important questions that have been discussed are e.g. 'what kind of enterprise would benefit from cloud computing?', 'how do you deploy a system that has scaled so much that you can't possible take everything down at once?', 'How do I store data if there is no concept of a database?', 'How to maintain integrity if the platform isn't going to support distributed transactions?', 'What kinds of architectures are suitable for such an environment?' and so much more

Even though I have been in this learning mode mostly, now on I believe I know enough about it to start sharing some of the knowledge I gained during these SIG's and my personal experiments. So expect yourself to see some more blog posts around here on the topic of Azure in the upcoming months...

Note: this also means that I'm very eager to hear any question you might have about the Azure platform. So in case you have any, send me a mail on yves ad goeleven dot com.

]]>

Azure - Introducing Azug.be

Yves — Sun, 21 Jun 2009 20:47:17 GMT

Once the summer is over, I'm going to join Kurt Claeys to start a new belgian user group on Azure.

I'm quite into this new platform for the last months, which you might have noticed as I've been blogging about some of my experiments with it like the cloud queue channel and how to build an EDA on top of Azure

So if you are interested in Azure as well, feel free to join us in our first event, which should occur early in september...

See you then.

]]>

Azure - EDA on the Azure Platform

Yves — Wed, 17 Jun 2009 19:19:58 GMT

I'm also very proud that my first article on the Microsoft Belux Architect Newsletter has been published today:

EDA on the Azure Platform

In this article I take a deep dive in the architectual challenges that a highly distributed system, such a Azure, poses to us humble architects.

I will also provide an architecture, called Event Driven Architecture, that can be used to overcome many of these challenges. I both explain what the essential parts of such an architecture are and how the Azure platform provides most of the required building blocks for implementing a system this way.

I've allready got great responses to the article, so you might be interested to take some time to read it yourself...

]]>

DDD - Slides Visug Talk

Yves — Wed, 17 Jun 2009 19:09:00 GMT

Yesterday I delivered a talk to the belgian Visual Studio User Group, Visug, about the aspects of DDD that are mostly targetted at developers...

I must admit that I really enjoyed the talk, there was great interest from the public, I got loads of questions. So I need to pay my gratitude to the audience.

In case you missed it, or you would like to review the content once more, here are the slides:

Domain Driven Design.pptx

]]>

Recent downtime

Yves — Fri, 05 Jun 2009 21:30:25 GMT

You might have noticed that the site has been down for a few days. My provider told me that they had issues with the configuration of the server that it was hosted on, and that they have trouble figuring out what is going on exactly

In the mean time, the site has been moved to another server and we are back up and running again...

]]>

EF - Lazy Loading

Yves — Wed, 13 May 2009 19:59:35 GMT

The ado.net team announced another critical feature that makes me consider EF as a viable option in the future: lazy loading

keep up the good work guys...

]]>

EF - Real POCO support

Yves — Wed, 13 May 2009 19:53:57 GMT

I just found the announcement that the Entity Framework will support real POCO from the next version on...

Definitly worth to keep an eye on these developments...

]]>

DDD - Microsoft Guidance

Yves — Wed, 13 May 2009 19:47:08 GMT

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 ...

]]>

DDD - Declarative design

Yves — Wed, 06 May 2009 20:12:39 GMT

Declarative programming is a programming style where the specification becomes executable, this can be achieved by either using an interpreted language like a DSL or runtime code generation such as many aspect oriented frameworks do.

This declarative programming style has a lot of merits to reduce the impact of changes in the design, but it can impose some risks as well as the effects of these specifications can't really be tested properly.

Many of the benefits of a declarative design can as well be reached by combining several of the previously discussed programming techniques such as intention-revealing interfaces, side effect-free functions, conceptual contours and closure of operations

A fully implemented specification pattern is a very good example:

var isAllowedToDrive = IsOlderThan(18) & DoesNotDrink();

Or a fluent interface

serviceProvider
.For<IMyService>()
.Return(new Mock<IMyService>());

By using an imperative language to achieve kind of a declarative programming style, allows you to both test the effects of the code, as you have an object in hands to test against, and the code is still concise and expressive which leads to a serious reduction in impact of changes.

]]>

DDD - Closure of operations

Yves — Mon, 04 May 2009 20:30:49 GMT

Most interesting objects end up doing things that can’t be characterized by primitives alone, so implementing it as a standalone class is not an option. But there are other options to limit the scope of a class, and thus the impact on refactoring, closure of operations for example.

Where it fits, define an operation whose return type is the same as the type of its arguments, as such making the operation closed under that type. Here is an example:

Pigment red = new Pigment();
Pigment blue = new Pigment();
Pigment purple = red.MixIn(blue);

Closure of operations can drastically simplify the model even if the closure is incomplete, in combination with primitives for example

Volume liquifiedNaturalGas = new Volume(1000, “m³”);
Volume naturalGas = liquifiedNaturalGas.ExpandBy(60.43);

]]>

I turned 30 today

Yves — Mon, 04 May 2009 20:23:52 GMT

I turned 30 today, party time...

]]>

DDD - Standalone classes

Yves — Thu, 30 Apr 2009 15:46:06 GMT

Low coupling is another fundamental in object design that will help minimize the impact of any refactoring effort. Don’t hesitate to go all the way and remove every single dependency if you can.

A dependency means an association, input parameter, return parameter or object instantiated internally, Each of these adds to the mental load as the developer needs to take side effects for them into account when making changes to the aggregate.
Primitives and .Net native types usually don’t count as mental overload, so try to expose or consume those instead. But keep in mind that the concepts represented by these primitives still do!

Don't go overboard on this pattern either, try not to dumb the model down by removing to much of these dependencies. My advise is to apply the standalone class pattern for classes that represent processes or calculations, as these typically don't depend to much on the semantics.

]]>

DDD - Conceptual Contours

Yves — Wed, 29 Apr 2009 20:14:03 GMT

Another important aspect that defines how well an aggregate or model can support refactoring is the scope of said part.

There is obviously to standardized way to figure out how large an aggregate should be. If the design is to coarse grained, then the interface doesn’t say everything the client may need to know. If the design is to fine grained, then the client might need to know to much about the aggregate in order to use it.

Evans states that, in his experience, the design is most flexible if it follows the conceptual contours of the business concepts. If you understand the concepts well and shape the aggregate according to the boundaries of this concept, any refactoring to it has least impact on the rest of the code because all relevant changes are scoped inside the aggregate and have little reason to leak out.

How to find the conceptual contour? Use your intuition! Observe the axes of change and stability during refactorings to align the model with the consistent aspects of the model that make it viable in the real world in the first place.

]]>

DDD - Assertions

Yves — Fri, 24 Apr 2009 20:08:58 GMT

When the side effects of operations are only defined implicitly then the delegation of commands will make the design a mess of cause and effects. Then the only way to understand what is happening is by learning the internal execution paths, which is obviously less then desirable.

Therefore you should make the side effects of commands explicit by using assertions, if your programming language allows this. Sadly enough C# does not, except for some experimental frameworks like Spec# and CodeContracts.

Unit tests, by creating tests for post and pre-conditions, can be used instead though. Especially well suited for specifying the side effects are BDD style tests which allow you to define the context, pre-conditions, in which the side effect occurs and allows you to show what the impact of the side effect is as an assertion in a test.

]]>

DDD - Side-effect free functions

Yves — Thu, 23 Apr 2009 20:46:17 GMT

Operations can be roughly divided in two categories: Operations that return results, from now on called queries, and those that cause state changes or side effects, from now on called commands.

It is important to separate the commands from the queries so that the software becomes more predictable. Queries never cause state changes, they are idempotent. Which means that any time they are executed, they provide the same result.

Make sure to limit the amount of commands, but obviously you can't do without. When you create a command, make sure it never return entities, preferably it has no result at all. This to make sure that developers don't use commands to retrieve data.

Further control side effects by moving complex logic into value objects Which must be immutable anyway. Also ensure that commands are only exposed on the interface of entities, as value objects must remain immutable.

Think of side effects as pushing the button which fires a missile, and you will understand the rules described before :)

]]>

DDD - Intention revealing interfaces

Yves — Wed, 22 Apr 2009 20:36:40 GMT

The object oriented paradigm of encapsulation is pretty much worthless if a developer that uses the interface of an object has to know the implementation details before the interface can be used appropriatly.

Therefore you should expose intention revealing interfaces, this means that instead of exposing the shape of the object, you should expose methods that clearly describe what the intent is without revealing how it does it's magic. The names of these interfaces should conform to the ubiquitous language so that team members can quickly infer their meaning.

An easy way to do this is to take the role of the client developer, write a test first and implement it afterwards. This forces you to think about the external appearance of the object, instead of the implementation details.

]]>

DDD - Supple design

Yves — Tue, 21 Apr 2009 20:01:53 GMT

Before software can suit the user, it should suit the developer and even after years, the software should be a pleasure to work on. Over time the design should be simplified, through continuous refactoring, so that it becomes easy to use.

As Evans phrases it so nicely. It's like a well-worn glove, it's sturdy but bends at the correct places.

Yet you will probably not achieve this on the first release, hard work and sheer persistence is required... in the upcoming posts I will show you some techniques that can help you to achieve a supple design.

]]>

DDD Talk - Some more seats added

Yves — Mon, 20 Apr 2009 21:24:13 GMT

On June 16th I will be presenting a session on Domain Driven Design for the VISUG, the sessions was fully booked quite quickly... so I'm happy to hear that they have added more seats :)

The talk will cover how DDD can be used as a pattern language. Secondly I will give you some real life design tips and tricks that will minimize the impact of refactoring during the life of your code. And finally I will give you some insights into how you can restructure your solutions so that you can focus on the most important parts.

If you are interested in one of the available spots, sign up now ...

]]>