How to Structure Jakarta EE Applications for Productivity Without Bloat
summary
Argues a concrete structure: one package per business concept (example flights), using boundary-control-entity with typically three classes for a microservice — a JAX‑RS resource, a (plain) facade/control, and an entity — and shows live Maven builds and code edits that produce a working REST endpoint. Claims DTOs are usually unnecessary (use JPA "select new" for projections), exceptions map to HTTP via WebApplicationException/@ApplicationException, reuse via shared jars rarely happens so no shared jars unless independently versioned.
AI-written summary · about
chapters (15)
- 0:00Introduction and philosophy
- 2:19Common structural anti-patterns
- 6:12Criticizing bureaucratic design
- 8:29Redefining package organization
- 11:13The BCE pattern approach
- 13:21Implementing the BCE pattern
- 18:04Handling cycles and dependencies
- 21:44The myth of code reuse
- 24:26Microservices and shared jars
- 28:09Exceptions in modern Java
- 31:50Dead patterns and DTOs
- 34:44Handling complex data queries
- 38:11Domain-specific libraries
- 40:05API design and REST resources
- 44:36Final summary and conclusion
related talks
01h 07mThe Java EE-stic Way of Coding
44mJava EE - And The Bloat Is Gone
10mpart1 – Adam Bien
49mJava EEFuture Is Now, But It Is Not Evenly Distributed Yet
50mJakarta EE 10: Modern & Lightweight Cloud Application Development
51mModern and Lightweight Cloud Application Development with Java and Jakarta EE
48mManaging Data in Jakarta EE Applications
10mpart2 – Adam Bien