Happy new year to all !!

First post of the year – On my “2011 year To-dos list”, I have got “Make at least one post per month”. We will see.

I already mentioned the new Layer model diagram in Visual Studio 2010 on a previous post (TechEd 2010 – Day #3). At the time I created a model diagram using one of my current projects (SteelVersion) and here is the result:

As you can see, the application was made of a few components and dependencies. The good thing for me was that from that date onwards I had a layer diagram that:

• Help me to visualize the relationships between my components;
• Help me Next time I will create or add projects to my solution (i.e. which layer and what are the dependencies rules attached to that layer);
• Could be used during compilation time to validate and notify me whether “I have broken or not any rules about the dependencies in my projects”;
• Could be used to communicate my application design to other architects/developers.

As in any system evolution, when things start to become “too big” (needs to be quantified and defined, but for this post, they were “big” for me :)), I have to revisit some parts of my code and check:

• Do I still need that part?
• Does it fit in this assembly?
• Or Should I split some functionality in another or new assembly?
• etc.

In other words, it is refactoring-time for the code. However, in this occurrence, I have got my little friend “my layer diagram”. I split my applications in 3 parts: an Explorer, a Checker and a Visualizer.

Here is the new layer diagram for the “Explorer” at the beginning of December 2010:

More components started to appear (due to the increase in functionality), but as a developer, I can see the evolution and refine it during the refactoring phase. At the end I have got a new layer diagram that test and validate the dependencies in my projects during compilation time. So, I carried developing and improving my “Explorer”. Here is the new diagram on 18th December 2010:

Although, there was not any circular reference between the assemblies, the “circular reference between layers” did not look pretty, or at least added confusion to my layer diagram. Nothing wrong technically: no circular references and the application was working. However, “visually” I did not like what I was looking at in my layer diagram. Again, the layer model tooling help me to visualize the dependencies of my projects (I like very much this tool 🙂

What happened? I added code to support new functionality, I had to overcome a few problems and find solutions for them. Sometimes, the solutions for some problems (here I had to introduce new functionality that required to run in a different Application Domain) are not built from “top-to-bottom” (i.e. Design->Code), but instead built from “bottom-to-top” (Code->Reverse Design) and might not look clear (or pretty). That is what I end up with here 😦

I refactored a little bit my application (as I said, nothing wrong technically), and I did a lot more to my layer diagram by introducing new layers (split the “BL” layer into two layers, “BL” and “Entities”). Here is the new layer diagram at the end of last week:

(30/12/2010 – Better things to do during a winter break, especially with so much snow this year – even in Paris! – than development, do not you agree? 🙂

Personally, I am quite happy about my latest layer diagram:

• “Looks clearer”
• Shows the dependencies and layers of my application
• Can be used to communicate with other people
• Validate and tests my projects during compilation time

Also, you could take a snapshot of your application layer diagram(s) at different point of time during the life cycle of your application (like I did over the past two months on my “Explorer” application) and by looking back at them:

• Have a better visualization of what has moved/been created/been removed in your projects
• Identify quickly what can be reused or be good candidates for reuse on other parts of your systems/applications  (here, what is inside of my “Cross Cutting” and “Helpers” layers).
• Understand and learn more about your application evolution and your refactoring decisions

I hope this was useful information.