LayeringPrinciples

application architecture

tags:

For the last few days I've been attending a workshop on enterprise software in Norway, hosted by Jimmy Nilsson. During the workshop we had a session where we came up and voted on a bunch of design principles.

The rules were this. Everyone could propose principles for good layering which were added to a list. There was little discussion of the principle - only clarification as needed. People could propose principles they liked or not - the rule was to capture principles that people had heard in the field.

Once we'd got a list, it was time to vote. We used a variant of DotVoting where everyone got 10 positive and 10 negative votes.

I've put the results below - principle followed votes in the format positive/negative.

Obviously you can't read too much into this list. While it was a good group of people, it was hardly a definitive source of enterprise development expertise. The principles are also worded somewhat loosely and there are overlaps and imprecisions that would be cleaned up if we'd had more than an hour for the exercise. However I suspect the list might provoke a little thought and discussion.

I asked people if there were things that surprised them. A couple of people were surprised that principles that they had heard often (and disliked) were trashed in the voting. (Separate development teams by layer and Rethrow exceptions at layer boundaries.) Similarly there was a surprise that "Business layer only uses abstractions of technological services" got such a strong vote even though it's rarely done in practice.

Share: