https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

我对此模式有疑问。数据库位于外层，但实际上如何工作？例如，如果我有一个仅管理此实体的微服务:

person{
  id,
  name,
  age
}

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.

Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes, functions, classes. variables, or any other named software entity.

Crossing boundaries. At the lower right of the diagram is an example of how we cross the circle boundaries. It shows the Controllers and Presenters communicating with the Use Cases in the next layer. Note the flow of control. It begins in the controller, moves through the use case, and then winds up executing in the presenter. Note also the source code dependencies. Each one of them points inwards towards the use cases.

We usually resolve this apparent contradiction by using the Dependency Inversion Principle. In a language like Java, for example, we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.

For example, consider that the use case needs to call the presenter. However, this call must not be direct because that would violate The Dependency Rule: No name in an outer circle can be mentioned by an inner circle. So we have the use case call an interface (Shown here as Use Case Output Port) in the inner circle, and have the presenter in the outer circle implement it.

The same technique is used to cross all the boundaries in the architectures. We take advantage of dynamic polymorphism to create source code dependencies that oppose the flow of control so that we can conform to The Dependency Rule no matter what direction the flow of control is going in.

最佳答案

The Database is at outter Layer but how would that work in reality?

public interface OrderRepository {
    public List<Order> findByCustomer(Customer customer);
}

public class HibernateOrderRepository implements OrderRepository {
      ...
}

And one of the use cases would be manage Persons. Manage Persons is saving / retrieving / .. Persons (=> CRUD operations), but to do this the Usecase needs to talk to a database. But that would be a violation of the Dependency rule

+-----+      +---------------+     +-----------+
|  db | -->  | use-cases-api | <-- | use cases |
+-----+      +---------------+     +-----------+

+-----+      +-----------+
|  db | <--  | use cases |
+-----+      +-----------+

If i get a GET /person/{id} Request should my Microservices process it like this?

public interface ControllerParams {
    public Long getPersonId();
}

@Path("/person")
public PersonRestService {

    // Maybe injected using @Autowired if you are using spring
    private SomeController someController;

    @Get
    @Path("{id}")
    public void getPerson(PathParam("id") String id){
       try {
           Long personId = Long.valueOf(id);

           someController.someMethod(new ControllerParams(){
                public Long getPersonId(){
                    return personId;
                }
           });
       } catch (NumberFormatException e) {
           // handle it
       }
    }
}

With this approach, software architects working in systems written in OO languages have absolute control over the direction of all source code dependencies in the system. Thay are not constrained to align those dependencies with the flow of control. No matter which module does the calling and which module is called, the software architect can point the source code dependency in either direction.

That is power!

gateway layer = interface OrderRepository => shouldnt the OrderRepository-Interface be inside of UseCases because i need to use the crud operations on that level?

public interface PlaceOrderRepository {
     public void storeOrder(Order order);
}

public interface CancelOrderRepository {
     public void removeOrder(Order order);
}

关于java - 整洁建筑设计模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52352815/