Proposed design principles for internal design

In my current project we are to implement additional functionality in an existing code base. The system is SOA-based, composed of many sub systems, each implementing a set of services, as detailed by the architectural guidelines given to the project. In practice this means that each sub system hosts a set of domain logic behind a façade of Java EE Stateless Session Beans or Message Driven Beans. As the service façade approach is described in detail in the guidelines, any guidelines of the internal design is equally absent. Therefore I’ve, with great inspiration from the DDD community, put together this list of design principles for proposed use within the project, but I think they could be equally applied to internal design of most administrative IT-systems. What do you think? Should something be added or subtracted?

General design principles

• Adhere to the Single Responsibility Principle (SRP), i.e. every module (class/method) has one responsibility, not several.
• Choose names from the business domain for classes, methods, attributes, parameters and variables.
• Use domain objects as parameters instead of primitives like string or int.
• Design the system such that domain classes can be unit tested individually.
• Each (part of a) sub system should use one design metaphor, either 
• domain centered - business logic placed in domain objects, preferable when changes to state is most important -  or
• service centered – business logic placed in stateless services that operate on data in DTO:s, preferable when the data flow is most important. 

From this follows

• Keep business logic and technical implementation details separate, i.e. do not combine these two types of complexity.
• Adhere to Command Query Separation (CQS), i.e. each method should be either a command (having a side-effect and possibly returning a result) or a query (returning a result without any side-effect).

On a more detailed level

• As a tool for communication use the following stereotypes for objects implementing the business domain logic:
• Value Objects – immutable, created when needed, not persisted.
• Entities – mutable (as per allowed by business rules), loaded/persisted through Repositories.
• Repository – interface describing load/persist of Entities.
• Factory – interface describing creation of Entities and Value Objects when external dependencies (to Repositories, Factories or Services) must be fulfilled.
• Service – stateless class housing business logic that operate on data in DTO:s
• Dependencies are preferably handled through dependency injection to facilitate loose coupling between objects.

Application of principles
These principles define a solid approach to design of new (sub) systems. When used in work with an existing code base it can be used for continuously applying small improvements in accordance with “the boy scout rule” and as vision to compare with current state in order to form a road map for larger refactoring efforts.

The only certification I'm proud of

It seams the popularity and importance of certifications goes up and down in the IT-industry. The only thing constant is the ongoing debate on whether certifications are valuable as a "receipt" on competence or a total scam. I think there is a value but the value vary greatly depending on the type of certification.

After a bit over ten years in the industry I've gathered a set of certifications. However, the value of them are in most cases very little over following a coarse or reading a book. I'm certified in both OOAD by IBM/Rational  and in Java programming by Sun/Oracle. I have also ample experience in both fields but I got the certifications prior to that, by just reading the books and completing a test. For my Scrum Master certification I didn't even have to complete a test, following a two day course was enough. This is the reason for this particular certification being so heavily criticised, and I agree, the "certification" does not bring any additional value. But the two day course was great for gaining fundamental knowledge on values and core practices and I have since practised implementing Scrum and other agile techniques and value systems successfully.

These types of certifications are, despite that it might involve hard work to complete them since they tend to test on so specific things, entry level in most cases and as such adding no more value than successfully completing an exam at a small course at university. But there are other types of certifications that are based on real world experience and proven capabilities evaluated by experienced software engineers. Within the Capgemini group we've had such certifications for different professions for a long time and more recently it has been aligned with the publicly known Open Group ITSC. This is a certification based on what I've done in real world assignments and I think it is also a valid quality guarantee for the knowledge and experience I can bring into a new project. This is the only certification I'm proud of!

Software Engineering Essential Reading 1 - Growing Object-Oriented Software, Guided by Tests

Under the title "Software Engineering Essential Reading" I plan to share short reviews of books and articles I find most useful and an essential read for every software engineer.

First up is an (in my opinion) outstanding book on Test Driven Development (TDD) written by Steve Freeman and Nat Pryce. The title is "Growing Object-Oriented Software, Guided by Tests" and, as the title suggests, this book is more about how to successfully build changeable and maintainable software using TDD than a technical book on a specific testing framework. Sure, through the book they are using jUnit 4.x and jMock2, but the book is not a go-through of framework features, rather it uses lots of example code to show how they "grow" (just like a gardener does with flowers) software. These frameworks just happens to be their favorite tools.

The book roughly consists of three parts:

1. First the authors go over their motivation for TDD and the principles and techniques they apply to both testing and OO-design and -implementation. Part of this is really heuristics to follow for a clean, readable and maintainable design of production code which also is greatly discusses in other books, but I like the fact that it is included here because it brings the whole picture of responsible software development rather than just explaining TDD ripped out of its context.
   
2. In the second part they go through a long (about 150 pages) example of "growing" an application using the principles an techniques from part 1. The example is very well done and easy to follow. In the beginning I felt it was very valuable, but at the end I thought it was running a bit long. But just as I was about to skip some pages the book went on into part three.
   
3. In the last part they wrap up and enforces their key ideas by going over their principles in more depth backed-up with the examples from part two. In many passages this part is so dense and right-to-the-spot that you have to pause a minute or so after each paragraph just to think over the truths that just were brought to you.

All in all, this is a truly great book and I would say it goes straight to the top of all SE-related books I've ever read. I strongly recommend anyone engaged in software development to get a copy.