Skip to main content

Posts

Showing posts from July, 2014

I Need to Stop Misusing Namespaces

At the recent NSBCon one interesting question that came about was how to structure a project. The panel consisting of various speakers had no answer, after all this is dependant upon the project in question. Therefore there is no right or wrong answer.However one point they were in unison about was splitting the domain and technical implementation of a project apart by the correct use of in namespaces.This is not the first time I've come across this, but I find myself breaking this principle on a regular basis. For example a typical project I work on looks like the following.ProblemsThe namespace reflects a technical implementation detail, and not the problem domain.Using Foo as an example, here the namespace is duplicated within the name of the types, which in turn defeats the point of namespaces.Another issue is that the types can be much longer than they need to be, which is often a criticism of enterprise software development, when the names of objects roll off the screen beca…

SOA Done Badly vs SOA Done Right

I was under the assumption I had been doing SOA for over 3 years. Previously I have had services which did stuff, these talked to other services which did other stuff and so on. We would group services around functionality.We would break these services down if they got too big to handle. Behind the scenes the services would talk to a single database. When it came to creating an application or system, these front end applications would invoke various services, which in turn invoked other services. This layered style of architecture worked for a while, so everything appeared to be fine.The overall architecture looked like this: Over time I began to question the benefit of this style. I spent more time coding than solving business problemsI spent more time debugging than solving problemsI spent more time fixing broken deploys than solving problemsI spent more time writing infrastructure (to glue services together) than solving problemsIt turns out this is actually quite a common style t…