{"id":111,"date":"2012-10-02T07:12:18","date_gmt":"2012-10-02T06:12:18","guid":{"rendered":"http:\/\/serverdude.dk\/?p=111"},"modified":"2012-10-02T07:22:46","modified_gmt":"2012-10-02T06:22:46","slug":"java-application-architecture","status":"publish","type":"post","link":"https:\/\/serverdude.dk\/?p=111","title":{"rendered":"Java Application Architecture"},"content":{"rendered":"

<\/a>\"\"Kirk Knoernschild<\/a>\u00e2\u20ac\u2122s book, Java Application Architecture: Modularity Patterns with Examples Using OSGi, ought to be made superfluous, but as it stands it is direly needed.<\/p>\n

\nAt least the first two parts: \u00e2\u20ac\u0153The Case for Modularity\u00e2\u20ac\u009d and \u00e2\u20ac\u0153The Patterns\u00e2\u20ac\u009d should be known by heart by any Java developer. It should be second nature for disciplined and professional developers.<\/p>\n

\nIn \u00e2\u20ac\u0153The Case for Modularity\u00e2\u20ac\u009d Kirk goes over the definition of what a module is, whether architecture is a phase carved in stone in the beginning of a project, or whether it is pervasive and should be attended to all the time. <\/p>\n

\nHow growing complexity must be countered by disciplined maintenance. <\/p>\n

\nWhy Technical Debt and Design Rot must be cleared to keep the source code from succumbing to the development death spiral.<\/p>\n

\nWhy cyclic dependencies must be rooted at all costs.<\/p>\n

\nAnd what the benefits of modular structures are.<\/p>\n

\nWhile you may think that a given piece of software is not ripe for modular extraction, because it will never be replaced or reused elsewhere. This is not the right attitude, as the first or second use of the source code is the test cases preferably developed in sync with the source code, either in a TDD or BDD way. It is simply easier to unit test a unit, no matter how big that unit is.<\/p>\n

\nFinally \u00e2\u20ac\u201c just to prove that this is not hot air preached from the pulpit \u00e2\u20ac\u201c Kirk refactors a small application in 7 steps each a tiny isolated step improving on the overall structure. This is how software should evolve once it has fallen prey to design rot.<\/p>\n

\nThe second part of the book, The Patterns, describes 18 patterns in 5 chapters, which Kirk has made available here<\/a>:<\/p>\n

\nThe Base Patterns: <\/p>\n