Architecture Assigns Responsibilities Before Files Multiply

A capstone architecture is not a screenshot of folders.

Start with responsibilities and information flow.

For a fictional match analyzer:

raw records
   |
Parser
   |
MatchRecord values
   |
ScoreService
   |
standings collection
   |
Formatter
   |
output

Each boundary should answer a different question.

Build a responsibility table

This is stronger than "Parser class, Score class, Main class" because responsibilities are visible.

Choose the data structure from operations

Your capstone must use at least one meaningful collection.

Write a decision record:

Data being stored:
Required operations:
Order requirement:
Duplicate rule:
Lookup rule:
Chosen structure:
Rejected alternative:
Tradeoff:

Examples:

• List<MatchRecord> when every event and order matter;
• Set<String> for unique tags/capabilities;
• Map<Integer, Integer> for team ID -> current total when replacement/update semantics fit.

Do not add a HashMap only to satisfy a rubric line. The operations must justify it.

Choose class versus record deliberately

A parsed immutable event often fits a record.

A service with behavior and dependencies often fits a class.

An entity with controlled state transitions may fit a class with encapsulated state.

Write the reason in domain terms.

Find interface boundaries that actually vary

Do not create an interface for every class.

Candidates include:

• output destination;
• formatting policy;
• scoring policy;
• data source abstraction when browser/JDK lanes differ.

Use an interface when the caller benefits from depending on a capability instead of one concrete implementation.

Package/full-JDK plan

Full-JDK projects should plan a readable source/test structure.

Example:

src/main/java/org/robotnix/capstone/
  App.java
  MatchRecord.java
  MatchParser.java
  ScoreService.java
  Formatter.java
  ConsoleFormatter.java

src/test/java/org/robotnix/capstone/
  MatchParserTest.java
  ScoreServiceTest.java

Browser-core projects may keep types in one source file for execution while still submitting the component/package plan.

Dependency direction

Draw arrows for who knows whom.

A formatter should not reach backwards into raw input files just because it can.

A domain service should not instantiate every external collaborator internally if substitution/testing is a stated requirement.

Architecture review

Before coding Version 1, challenge the diagram:

• Which component knows too much?
• Which class exists only because "Java uses classes"?
• Is any inheritance relationship really just a has-a relationship?
• Where is validation enforced?
• Which requirements have no clear owner?

Revise the design before multiplying implementation work.

Evidence

Submit a component diagram, responsibility table, data-structure ADR, class/record decisions, and at least one dependency/interface decision. Every major requirement from Lesson 1 should have an owner in the architecture.