Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Thomas Ferris Nicolaisen
Is this you? Claim Profile »
9 months ago
in I received an overwhelmingly warm welcome as the new chief scientist at Steria on Thinking inside a bigger box
Congrats on your new job! And welcome back to the consulting buffét :)
11 months ago
in [link] Package by feature on Thinking inside a bigger box
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 :)
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 :)
1 year ago
in Rails #1b: Heroku on Thinking inside a bigger box
Just a tiny beware on outsourcing to EC2 in case you need more than 4 nines of uptime on your rails app.
1 year ago
in Agile and contract bids on Thinking inside a bigger box
Excellent and inspiring read. CC'ed it to our people who do this stuff :)
