public class QuoteResource {
    private final QuoteService quoteService;

    public QuoteResource(QuoteService quoteService) {
        this.quoteService = quoteService;
    }
}

- siapa owner lifecycle object ini?
- apakah object ini singleton, request-scoped, atau transient?
- apakah object ini thread-safe?
- apakah object ini membawa tenant/user/request state?
- apakah dependency graph bisa dibangun saat startup?
- apakah dependency ini mudah diganti di test?
- apakah konfigurasi dan secret masuk dengan cara aman?
- apakah ada hidden global state?

Container responsibility:
- know which implementation satisfies which type
- create object in correct order
- inject dependencies
- manage lifecycle/scope
- fail startup if graph invalid

Dependency Injection solves construction.
It does not solve coupling, state ownership, or bad boundaries.

@Path("/quotes")
public class QuoteResource {
    private final QuoteService quoteService = new QuoteService(
        new QuoteRepository(new DataSourceFactory().create()),
        new PricingClient()
    );
}

- resource tahu terlalu banyak detail construction
- sulit mengganti implementation untuk test
- sulit mengatur lifecycle connection pool/client
- setiap resource bisa membuat dependency mahal berulang
- konfigurasi tersebar
- shutdown/cleanup tidak jelas
- observability wrapper sulit dipasang konsisten

@Path("/quotes")
public class QuoteResource {
    private final QuoteService quoteService;

    @Inject
    public QuoteResource(QuoteService quoteService) {
        this.quoteService = quoteService;
    }
}

- Jersey ResourceConfig
- HK2 AbstractBinder
- CDI bean discovery
- manual application bootstrap
- Servlet initializer
- main method embedded server
- framework-specific module/configuration class

public class AppBinder extends AbstractBinder {
    @Override
    protected void configure() {
        bind(QuoteService.class).to(QuoteService.class).in(Singleton.class);
        bind(PostgresQuoteRepository.class).to(QuoteRepository.class).in(Singleton.class);
        bind(PricingHttpClient.class).to(PricingClient.class).in(Singleton.class);
    }
}

@ApplicationScoped
public class QuoteService {
    private final QuoteRepository repository;

    @Inject
    public QuoteService(QuoteRepository repository) {
        this.repository = repository;
    }
}

Business code should not know how the whole application is assembled.

- Jersey/HK2 internal integration
- plugin lookup
- dynamic provider lookup
- framework bridge

public Quote calculate(QuoteCommand command) {
    PricingClient client = ServiceLocator.current().get(PricingClient.class);
    return client.price(command);
}

public class QuoteService {
    private final PricingClient pricingClient;

    public QuoteService(PricingClient pricingClient) {
        this.pricingClient = pricingClient;
    }
}

public class QuoteService {
    private final QuoteRepository repository;
    private final PricingClient pricingClient;
    private final Clock clock;

    @Inject
    public QuoteService(
        QuoteRepository repository,
        PricingClient pricingClient,
        Clock clock
    ) {
        this.repository = repository;
        this.pricingClient = pricingClient;
        this.clock = clock;
    }
}

- dependencies are explicit
- object can be immutable after construction
- no partially initialized state
- easy to test without container
- impossible to forget mandatory dependency

QuoteService service = new QuoteService(
    fakeRepository,
    fakePricingClient,
    fixedClock
);

If a class cannot be constructed in a unit test without the DI container,
its dependency boundary may be too framework-coupled.

@Inject
private QuoteService quoteService;

- dependency is hidden from constructor
- object can exist in invalid partially injected state
- hard to instantiate in unit tests
- encourages mutable non-final fields
- harder to reason about lifecycle

Use constructor injection for application code.
Use field injection only when framework constraints or internal standard justify it.

public class QuoteService {
    private AuditPublisher auditPublisher = AuditPublisher.noop();

    @Inject
    public void setAuditPublisher(AuditPublisher auditPublisher) {
        this.auditPublisher = auditPublisher;
    }
}

- optional dependency
- backward-compatible extension
- framework lifecycle callback
- test-only override

- mandatory dependency
- security dependency
- repository/client dependency required for correct behavior

public class ExportService {
    private final Provider<ExportJobContext> jobContextProvider;

    @Inject
    public ExportService(Provider<ExportJobContext> jobContextProvider) {
        this.jobContextProvider = jobContextProvider;
    }

    public void runExport() {
        ExportJobContext ctx = jobContextProvider.get();
        // use ctx
    }
}

- object is expensive and should be lazy
- object is request-scoped but injected into singleton
- object needs runtime parameter
- object lifecycle must be controlled explicitly
- object creation can fail and needs local handling

Provider<X> used everywhere because dependency graph is circular or scopes are wrong.

public interface PricingRequestContextFactory {
    PricingRequestContext create(TenantId tenantId, CorrelationId correlationId);
}

How many instances exist, and how long do they live?

- stateless singleton services
- singleton repositories/clients backed by pools
- request-scoped context holders
- explicit factories for runtime-specific objects

- stateless application services
- repository objects that use DataSource
- HTTP client wrapper with connection pool
- Kafka producer wrapper
- configuration snapshot
- object mapper if immutable/configured once
- metric registry wrapper

- object storing current user
- object storing current tenant
- object storing current request body
- mutable workflow state
- non-thread-safe formatter/client
- per-request accumulator

Singleton object must be thread-safe or effectively immutable.

@Singleton
public class QuoteContext {
    private String currentTenantId;
    private String currentUserId;
}

- pass tenant/user explicitly as method argument
- use request-scoped context if framework-supported
- use immutable command object

- authenticated principal
- tenant context
- correlation context
- request metadata
- permission context
- request-local cache

public class RequestContext {
    private final TenantId tenantId;
    private final UserId userId;
    private final CorrelationId correlationId;

    public RequestContext(TenantId tenantId, UserId userId, CorrelationId correlationId) {
        this.tenantId = tenantId;
        this.userId = userId;
        this.correlationId = correlationId;
    }
}

Request-scoped object is only valid during request lifecycle.

@Singleton
public class QuoteService {
    @Inject
    private RequestContext requestContext;
}

quoteService.createQuote(command, requestContext);

Singleton service depends on request-scoped context.

- container injects proxy and it works only inside active request
- request context unavailable in background thread
- context leaks if ThreadLocal not cleared
- unit tests miss issue
- async tasks fail after response returned

Convert short-lived runtime context into immutable command/context value at boundary.
Pass it explicitly.

@Inject
@Named
@Qualifier
@Scope
@Singleton

Jakarta Inject defines common injection annotations.
It does not itself provide the full container runtime.

- HK2 in Jersey environments
- CDI in Jakarta EE environments
- Spring if integrated separately
- custom/manual wiring

- which container processes @Inject
- which scopes are supported
- how resource classes are instantiated
- whether CDI integration is active

- object created by HK2 cannot see CDI bean
- object created manually cannot receive injection
- duplicate binding for same interface
- ambiguous injection with multiple implementations
- scope annotations interpreted differently

public interface QuoteRepository {
    QuoteRecord findById(QuoteId id);
    void save(QuoteRecord quote);
}

public class PostgresQuoteRepository implements QuoteRepository {
    private final DataSource dataSource;

    @Inject
    public PostgresQuoteRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }
}

QuoteRepository -> PostgresQuoteRepository

- database repository
- external HTTP client
- Kafka publisher
- clock/time provider
- feature flag provider
- secret/config provider
- audit publisher

IQuoteService, QuoteServiceImpl, QuoteServiceFactory, QuoteServiceProvider

PricingClient can mean:
- internal pricing engine client
- mock pricing client
- legacy pricing client
- tenant-specific pricing client

@Qualifier
@Retention(RUNTIME)
@Target({ FIELD, PARAMETER, METHOD, TYPE })
public @interface LegacyPricing {}

@Inject
public QuoteService(@LegacyPricing PricingClient pricingClient) {
    this.pricingClient = pricingClient;
}

Does the qualifier describe a stable architectural role,
or is it hiding environment-specific branching?

String timeout = System.getenv("PRICING_TIMEOUT_MS");

public class PricingClientConfig {
    private final Duration connectTimeout;
    private final Duration readTimeout;
    private final URI baseUri;
}

public class PricingHttpClient {
    private final PricingClientConfig config;

    @Inject
    public PricingHttpClient(PricingClientConfig config) {
        this.config = config;
    }
}

- config validated at startup
- defaults are explicit
- test can supply config
- no scattered env lookup
- config can be documented

- missing required binding
- invalid config value
- duplicate ambiguous binding
- secret unavailable
- malformed URI
- invalid timeout

Service starts successfully but first request fails because dependency is missing.

Not every dependency should be hard-required at startup.

QuoteService -> PricingService -> QuoteService

- service boundary too broad
- orchestration mixed with domain operation
- event publishing mixed with command handling
- helper class became god service
- bidirectional module dependency

Use Provider everywhere to break cycle.

- extract shared domain policy
- split orchestration service
- introduce event boundary
- pass data instead of service
- invert dependency through interface owned by lower-level module

@Singleton
public class QuoteAccumulator {
    private final List<QuoteLine> lines = new ArrayList<>();

    public void add(QuoteLine line) {
        lines.add(line);
    }
}

public class QuoteDraft {
    private final List<QuoteLine> lines;
}

Keep mutable aggregation as local variable within request method/service method.

Mutable request data should not live in singleton beans.

- Does it have mutable fields?
- Are mutable fields thread-safe?
- Does it use non-thread-safe Java types?
- Does it cache per-request data?
- Does it wrap a thread-safe client/pool?
- Does it mutate config after startup?

- DataSource/connection pool wrapper
- immutable config object
- stateless service
- ObjectMapper if configured once before use
- HTTP client designed for concurrent use

- SimpleDateFormat
- mutable ArrayList/HashMap without protection
- per-request context holder
- non-thread-safe SDK client if not documented as thread-safe

class QuoteServiceTest {
    @Test
    void rejectsExpiredCatalogVersion() {
        QuoteRepository repo = new InMemoryQuoteRepository();
        PricingClient pricing = new FakePricingClient();
        Clock clock = Clock.fixed(...);

        QuoteService service = new QuoteService(repo, pricing, clock);

        // assert behavior
    }
}

- Clock
- UUID generator / ID generator
- repository interface
- external client interface
- feature flag provider
- event publisher
- audit publisher

- binding correctness
- resource wiring
- provider registration
- scope behavior
- integration with Jersey/CDI/HK2

PricingClient interface
  -> ObservedPricingClient
      -> ResilientPricingClient
          -> SigningPricingClient
              -> RawHttpPricingClient

- metrics/tracing
- retry/circuit breaker
- request signing
- error mapping
- raw HTTP call

Every call site manually adds retry/logging/signing.

Compose decorated dependency once at application boundary.

Is resilience/telemetry/security applied at the dependency boundary,
or scattered across business logic?

@Singleton
public class PricingRules {
    private TenantId currentTenant;
    private RuleSet currentRules;
}

public interface PricingRuleProvider {
    RuleSet rulesFor(TenantId tenantId, Instant effectiveAt);
}

RuleSet rules = pricingRuleProvider.rulesFor(command.tenantId(), command.effectiveAt());

DI supplies capabilities.
Request supplies context.

if (System.getenv("ENV").equals("prod")) {
    return new RealPricingClient();
} else {
    return new MockPricingClient();
}

Binding layer chooses implementation based on validated profile/config.
Application code depends on PricingClient.

- How are profiles selected?
- Which bindings differ by environment?
- Are non-prod mocks accidentally deployable to prod?
- Are fail-safe defaults explicit?

1. Who created this object?
2. Was it created manually or by container?
3. Which container owns it: HK2, CDI, Servlet, custom bootstrap?
4. What scope does it have?
5. Is the dependency mandatory or optional?
6. Is there more than one implementation?
7. Is there a qualifier/name involved?
8. Is this running in HTTP request, background job, Kafka consumer, or startup?

- constructor annotations
- field/setter annotations
- HK2 binders
- CDI annotations
- ResourceConfig registration
- package scanning configuration
- startup logs
- dependency graph error
- test bootstrap

A DI bug that appears only under load is often a scope/thread-safety bug.

[ ] Does the class use constructor injection for mandatory dependencies?
[ ] Are dependencies explicit and minimal?
[ ] Is the scope correct?
[ ] Is every singleton thread-safe or immutable?
[ ] Is request/user/tenant state kept out of singleton objects?
[ ] Are multiple implementations disambiguated with stable qualifiers?
[ ] Are config objects validated at startup?
[ ] Are secrets handled through secure secret mechanism?
[ ] Are external clients wrapped consistently with timeout/resilience/telemetry/security?
[ ] Does business logic avoid service locator/static globals?
[ ] Can core behavior be unit-tested without DI container?
[ ] Are circular dependencies avoided?
[ ] Is shutdown/cleanup ownership clear?

[ ] Which DI mechanism is actually used: HK2, CDI, Spring, manual, or mixed?
[ ] Are JAX-RS resources constructed by Jersey/HK2, CDI, Servlet, or manually?
[ ] Is `@Inject` processed by HK2 or CDI?
[ ] Which scope annotations are valid in the runtime?
[ ] Are resources per-request or singleton?
[ ] Are providers singleton by default?
[ ] Where are HK2 binders registered?
[ ] Is CDI integration enabled?
[ ] Is `beans.xml` present and relevant?
[ ] Are there custom factories/producers?
[ ] Are config/secret objects injected or accessed directly?
[ ] Are tenant/user/request contexts request-scoped, ThreadLocal, explicit argument, or header-only?
[ ] Are there known patterns for mocking dependencies in tests?
[ ] Are external clients decorated with resilience/telemetry/security wrappers?
[ ] Are there internal architecture guidelines for dependency scope?

1. DI should make dependency graph clearer, not more mysterious.
2. Singleton is safe only when state is immutable or thread-safe.
3. Request context should be explicit at domain/integration boundary.
4. Configuration should be typed, validated, and owned.
5. Secret handling is not normal config handling.
6. Service locator belongs near framework boundary, not domain logic.
7. Provider/factory is for lifecycle/runtime variability, not hiding cycles.
8. Tests should not require container unless testing container behavior.
9. DI errors are often architecture signals.
10. The composition root is production-critical code.

- Who constructs this resource?
- What dependencies does it use?
- Are they constructor, field, or setter injected?
- What scope does each dependency have?
- Which dependencies are singleton?
- Which carry request/tenant/user state?
- Can the resource logic be unit-tested without container?
- Where is the binding/producer/factory registered?
- What would fail at startup vs first request?