I want to understand the difference between Kruchten's Logical and Development view when using a microservice architecture.

Krutchen describes the software architecture model 4+1 model with four different views.


The logical architecture primarily supports the functional requirements — what the system should provide in terms of services to its users.


The development architecture focuses on the actual software module organization on the software development environment. The software is packaged in small chunks — program libraries or subsystems — that can be developed by one or a small number of developers.

As I understand, the logical view uses class diagrams and state diagrams to illustrate the components. And the Development view uses a Package diagram. However, I have also found a source that says that the development view uses class diagrams.

The question then is how do they differ, and what is the correct definition of the views? What diagram form would I use to illustrate a microservice architecture?

1 Answer 1


It is indeed a confusing question: very often the decomposition into microservices (which would be Krutchen’s development view) is guided by the domain model (the logical view) and at a very granular level, so that both are completely aligned.

Keep in mind however that this alignment is more a result of some specific choices and there are many more decomposition strategies, such as by business capability, by technical criteria to obtain self-contained services, or by team. In these cases, the distinction between the views will appear more obvious.

The logical view is based on the requirements and the domain design independently of any choice about how this design is to be implemented. You’d probably be interested in this view in bounded contexts and domain design. The development view will look into how this design can be broken down and “packaged” for the implementation.

  • Thank you for the answer and the details. Especially the fact to acknowledge that using Krutchens model can be confusing. I will keep your notes in mind when creating my arguments.
    – A.Dumas
    Commented Sep 8, 2021 at 6:12
  • as a follow up comment. I needed to read your response several times to understand what you trying to say. Meaning that there is far more information behind each point. It the moment I still try to understand how different decomposition strategies yield clearer view. Thanks again for the explanation.
    – A.Dumas
    Commented Sep 12, 2021 at 7:09
  • @A.Dumas What I meant to say is that the most frequently used (although not always justified) decomposition strategy of a system into microservices, lead to a one-to-one relation between logical elements and development elements. But this is just a special case. Microservices are about independent deployment and not about having a service per class. Other strategies may be more suitable. And these may lead to very different logical and development views.
    – Christophe
    Commented Sep 12, 2021 at 8:27
  • The problem is that the suitability of each decomposition strategy is very dependent on the context. I realize that until you’ll have some concrete examples of two or three of them, my rather brief explanation might sound somewhat abstract.
    – Christophe
    Commented Sep 12, 2021 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.