Re: Agile and contract bids

Thomas Ferris Nicolaisen — Sun, 17 Feb 2008 16:39:21 -0000

Excellent and inspiring read. CC'ed it to our people who do this stuff :)

Re: Rails #1b: Heroku

Thomas Ferris Nicolaisen — Sun, 24 Feb 2008 17:25:49 -0000

Just a tiny beware on outsourcing to EC2 in case you need more than 4 nines of uptime on your rails app.

Re: [link] Package by feature

Thomas Ferris Nicolaisen — Wed, 06 Aug 2008 18:58:10 -0000

Count me as package by feature (or group of features). A package is for me merely a way of hiding implementation/internal classes. The book Effective Java 2nd ed. explains this in Item 13: Minimize the accessibility of classes and members.

Although I traditionally followed the by-layer rule just because everyone else did it, this was because I didn't understand the potential of using package-private (i.e. didn't know Java). Instead we tended to use Maven multi-module projects to seperate layers. These give you an extra bonus of enforcing directional dependencies between modules (don't access the web layer from the dao, etc). But it seems that people have become lazy with the use of traditional moduling with packages..

I recently added a new piece of functionality to our project. The use case was evaluating an organization number to decide what sort of insurances your company can buy online. I started off by making a new service, EvaluationService. I put it in its own package called 'evaluation'. I introduced a domain object called CustomerEvaluation (the result of doing an evaluation with the service), which I placed in our 'domain' package (by layer), but I would've rather put it in the 'evaluation' package (by feature). We still put all our exceptions in an 'exceptions' package, btw. These conventions are more for traditional reasons than for any good reason.

Anyway, I then implemented the EvaluationService with lots of underlying bits and pieces like IndustryCodeService, LegacyCodeTranslator and so on, all of which I dumped into the 'evaluation' package and made them package-private because they were just details needed to get the EvaluationService working. The evaluation package now feels really clean. It has its own Spring-context, its own nice set of tests, and one single public API exposed in the EvaluationService (and the CustomerEvaluation object).

If another piece of functionality ever needs the IndustryCodeService, I'll probably drag it out of the 'evaluation' package, make it public and create an 'industry-code' package that both existing packages can depend on.

If it became necessary to enforce that the industry-code package would not create circular references by depending 'evaluation' or another, I would move it into another maven module (project) higher up in the dependency hierarchy. This would be seperating layers for the reason of enforcing good design, I suppose.

Classes could still be in the same package while being in different projects/modules.. Haven't played around too much with that approach but it feels like it has potential. Wow, long comment better quit my rambling now. Feature package +1 :)

Re: I received an overwhelmingly warm welcome as the new chief scientist at Steria

Thomas Ferris Nicolaisen — Wed, 24 Sep 2008 16:28:29 -0000

Congrats on your new job! And welcome back to the consulting buffét :)

Disqus - Latest Comments for Thomas Ferris Nicolaisen

Re: Agile and contract bids

Re: Rails #1b: Heroku

Re: [link] Package by feature

Re: I received an overwhelmingly warm welcome as the new chief scientist at Steria