Entity-Control-Boundary (ECB) architectural pattern matches perfectly with our pattern language

domain structure is an Entity, the Control is a service, and the Boundary is realized with a facade

In simpler cases the facade and service can collapse, and a service would be realized only as a facade's method in that case

DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.

With JDK 1.5 and the advent of generics, it is possible to build and deploy a generic, convenient, and typesafe DAO once and reuse it from variety of services

key ingredients of a service-oriented component: Facade: Provides simplified, centralized access to the component and decouples the client from the concrete services. It is the network and transaction boundary. Service: The actual implementation of business logic. Domain structure: This is a structure rather than an object. It implements the component's persistence and exposes all of its state to the services, without encapsulation.

This convention not only standardizes the structure and improves maintainability, but also allows automatic dependency validation with frameworks like JDepend, Checkstyle,  Dependometer, SonarJ, or XRadar. You can even perform the validation at build time. If you do, the continuous build would break on violation of defined dependencies. The rules are clearly defined with strict layering: a facade may access a service, and the service a domain object, but not vice versa

differences between CDI beans and EJBs is that EJBs are : Transactional Remote or local Able to passivate stateful beans freeing up resources Able to make use of timers Can be asynchronous

Stateless EJBs can be thought of as thread safe single-use beans that don’t maintain any state between two web requests

Stateful EJBs do hold state and can be created and sit around for as long as they are needed until they are disposed of

one of the most important value propositions for frameworks like Spring has been the ability to easily extend the framework or integrate third-party solutions

SPI allows you to register your own beans, custom scopes, stereotypes, interceptors and decorators with CDI even if is it not included in the automatic scanning process (such as perhaps registering Spring beans as CDI beans), programmatically looking up CDI beans and injecting them into your own objects (such as injecting CDI beans into Spring beans) and adding/overriding annotation-metadata from other sources (such as from a database or property file)

SPI can be segmented into three parts. Interfaces like Bean, Interceptor and Decorator model container meta-data (there are a few other meta-data interfaces such as ObserverMethod, Producer, InjectionTarget, InjectionPoint, AnnotatedType, AnnotatedMethod, etc). Each meta-data object encapsulates everything that the CDI container needs to know about the meta-data type