Trade-off means that there is no black and white choice, you always have a trade-off, the point is to make an informed decision not one influenced by emotion or fashion.
Dan talks about 4 topics and the usual decisions that goes along:
- Team composition: co-located or distributed ? feature or layer team ? experienced or inexperienced ? small or big ?
- Development style: automated or manual build ? test-first ? TDD ?
- Architecture: monolith or components ? resources or messages ? synchronous or asynchronous ? single event loop or multiple threads ?
- Deployment: automated or manual deployment ? vertical or horizontal scaling ? hosted or in-house ? bespoke or commodity ?
Common Sense is better than Common Practice
This is a quote when he talks about times when tests are the worst thing to do given the trade-offs: longer time-to-market, disposable application, low return on investiment, lower agility for change, etc.
Design is all about the decisions you made
All your architecture is about the informed decision you made. Your decision can have a system wide impact in the quality attributes of the system or a localized one, that define respectively macro (cross-system) and micro (system- internal) architecture as Stephan Tilkov stated it in his presentation. Design is all about the macro and micro level decisions you made.
Stephan also talks about the objectives and rules that goes with each architecture. Here are some topics that can have rules associated with, each one categorized as macro or micro:
|UI Integration||Development tools|
|Data formats||Process / Workflow controls|
|BI Interface||Design Patterns|
To take account of time, each set of rules is versionned. With the assumption that two systems in the same Rules version can interoperate seamlessly.
In the beginning of a project the objectives are more the following: ease of development, homogeneity, simplicity, etc. and as time goes by (and as the artefacts increase) the preponderant objectives becomes: modularity, decoupling and autonomy. Nice point : Stephan talks about the domain architecture, that is often the most stable one.
Each time you mutualize something between two components (code, data) you introduce a new coupling
The inverse of « DRY » (Don’t Repeat Yourself) is « Decoupled » !
That’s particularly true for data replication, often considered bad but replication permits more autonomy and avoid synchronous calls that directly impact availability and reliability. The solution is asynchronous: use events for notifying interested components of a change.
The second keyword I notice several times is « entanglement » (actually there are several keywords but I grouped them: cyclic dependencies, braid, intricacies). Reducing dependencies is a point that I promote for a long time. Dependency is often added as a micro level decision but every time one is added it augments the overall system complexity. I often use Structure 101 to manage the dependencies in the Java system I work with and I’m very satisfied with it.
programmers know the benefits of everything but the trade-offs of nothing