Agile Component Design

The pattern movement was started last millennium. Very talented and experienced developers have documented how to solve common problems elegantly and effectively. Depending on the programming language, you are using different idioms are preferred.

The way to solve the same problem is different in Java, Scala, C++, Python, or C#.

You should know all regular structural, behavioral, and creational patterns [1]. Explore your programming language and discover how idioms and patterns have evolved between major releases. For example, lambda expressions and streams introduced in Java 8 - released Spring 2014 - completely transform the solution for regular business logic.

Records introduced in Java 14 - released Spring 2020 - have a huge impact on how your architecture deals with data transfer objects – DTO – and immutability ^[1].

Stop inventing the wheel again and again. Avoid Not Invented Here syndrome. Your current problem was already solved multiple times. Explore open source solutions, read posts, study books. Select the most adequate solution and fill free to adapt and improve it.

Instead of searching for a solution for days, post your question on an adequate forum or on Stack Overflow. Fill free to improve the suggested solutions.

Become more efficient and use the wisdom of all these developers accessible through the Internet. Always verify the quality and adequacy of their proposed solutions.

Know your programming language and the associated standard libraries. They are part of your technology stack. Wisdom is coded in this code. Standard patterns are implemented in almost all packages. Idioms are encoded everywhere.

See how Java deals with human and machine time with java.time package. Decades of trials and errors were necessary to finally create balanced and simple to use time abstractions. The author of Joda Time experimented years before he wrote the java time package – JSR 310 – introduced in Java 8. All these decisions and learning are encoded in this code.

You want to create a clean architecture [2] you are proud of. You must first write a clean code [3]. Clean architecture builds up on clean code. Promote clean code in your agile team. Agile code is clean code.

Do not fall to the fallacy to draw beautiful and useless UML diagram and write thick Software Architecture Design documents.

The real architecture is hidden in the source code of your product. You still document all major Architectural Decisions.

If you are developing in Java, you should use the current features of the programming language. For example, with Java 14, you have access to:

The entropy of the source code increases over time. Only continuous and aggressive refactoring mitigates the degenerescence of your application [4, 5, 6, 7]. Each time you correct an error or add a new functionality refactor your code. Remove smells, compiler warnings and migrate older code to use newer and better features of your programming language.

Your users want a working application. Write acceptance tests insuring all relevant functions are tested through your continuous integration pipeline. You guarantee your users the application behaves as specified.

Testability and changeability of your application are architectural aspects. You must have a way to verify these non-functional requirements. Test-driven development is a proven approach to fulfill these requirements and validate them continuously.

Continuous integration and delivery are the mechanisms to continuously validate and verify all functional and non-functional requirements are correctly implemented [8]. You guarantee your users and customers that any software delivery they get is compliant and correct.

Each time you find a discrepancy, add a test validating the requirement behind this fault. The same error will never happen again.