Who must create services with package modifier if I implement architecture from "Clean Architecture" book

Question

I read Uncle Bob's book - "Clean Architecture". There is one chapter written by Simon Brown. He revised a few types of architecture. He offers to incapsulate implementations in packages.

If I bring the packages back and mark (by graphically fading) those types where the access modifier can be made more restrictive, the picture becomes pretty interesting (Figure 34.8)

I implemented one approach with spring DI:

com.my.service

public interface OrderService {
    List<Order> getOrders();
}

and implementation:

com.my.service.impl

@Service
class OrderServiceImpl implements OrderService {
    //...
}

It works fine because Spring finds OrderServiceImpl marked @Service annotation. OrderServiceImpl is encapsulated as on the (Figure 34.8.)

But how can I repeat this without Spring annotation configuration? For example, if I use Spring java configuration, I should create a bean like this:

@Configuration
public class AppConfig {

    @Bean
    OrderService orderService(){
        return new OrderServiceImpl();
    }
}

But OrderServiceImpl has a package modifier.

If I don't use Spring, what should I do to repeat this approach?

Answer 1

I would place the configs according to the different packaging types.

Package by layer

I would create

• WebConfig in the com.mycompany.myapp.web` package that creates the beans for the web layer
• ServiceConfig in the com.mycompany.myapp.service package that creates the beans for the service layer
• DataConfig in the com.mycompany.myapp.data package that creates the beans for the data layer

Package by feature

I would create

• OrdersConfig in the com.mycompany.myapp.orders package that creates the beans for the orders feature

Ports and adapters

I would create

• WebPortsConfig in the com.mycompany.myapp.web package that creates the web beans.
• OrderConfig in the com.mycompany.myapp.domain package that creates the domain objects of the ports and adapters architecture.
• DatabaseAdapersConfig in the com.mycompany.myapp.database that creates the database adapter beans.

Package by component

I would create

• WebConfig in the com.mycompany.myapp.web package that creates all the beans for the web stuff.
• OrdersConfig in the com.mycompany.myapp.orders package that creates all the beans for the order component.

Deployment Units

Even if the spring configs are in the same package they must not be in the same deployment unit or module.

E.g. you can create a service.jar and a service-config.jar to separate the pure application from the framework stuff.

service.jar
+- com
   +- mycompany
      +- myapp
         +- service
            +- OrderService.class
            +- OrderServiceImpl.class


service-config.jar
+- com
   +- mycompany
      +- myapp
         +- service
            +- ServiceConfig.class

Then you just have to put both jars on the classpath and you can either add com.mycompany.myapp.service to your component scan in your main class or you directly reference the ServiceConfig.