hexagonal architecture #39
Conversation
|
Hello @baumeister25, regarding your question:
My view of that is that factory does not call the service. All of the data neeed for the construction is passed to the factory via method call arguments, and all of the data which is necessary for construction is retrieved in one "one-layer-up", which would basically be the use case layer in this case. I tend to view the use case as general orchestrator, and all of the externalities should be handled there. Of course this can grow too large in time, and that is when I would decide to slowly start introducing additional helpers for use case, which are often designated as "domain services" in hexagonal architecture. If this approach is not feasible, then nothing would speak against moving the factory one layer up, basically to colocate it with the use case and/or services. This is the point at which I would find following the architectural guidelines to be motivated more by ideals of architecture, then by actual benefits of it, since the factory obviously belongs together with entity definition. Additionally I really dislike the current package structure, because it is cut by technical and architectural responsibilities, instead of by functionality provided by packages. While such structure is basically "one-size-fits-all" solution for starting projects it will lead to architecture where non-related things are packaged together. Further one ugly effect is that any change to functionality will almost certainly span many packages, reducing the maintainers certainty that no unrelated functionality has been changed. |
|
Hi @thecooldrop, thanks for the feedback. Regarding the package structure, my idea was that the division into business components is on a higher level (the business component a in the picture). |
|
I have the understanding that the services refer to the domain, as a separate package for the domain services. That means, the service would be under the domain package. |
A factory should not use further service or do some "black magic" to build an object. It should get all necessary data to create the object.
Oh, okay, now I understand. In that case I largely agree with the package structure, and find it sufficient for demonstration purposes |
modules/ROOT/images/hexagonal_component_architecture_overview.drawio.svg
Outdated
Show resolved
Hide resolved
|
After today's discussion with @chris-toenjes-deye we came to the conclusion to add/change the following points:
|
After dicussing with @chris-toenjes-deye we decided the following points: - Services should be marked optional. The usual business logic belongs inside the use case implementation. Only in cases of better structuring or reusable business logic, it should be moved to a service - A differentiation between inbound and outbound ports is added. Inbound ports are used to describe use cases the core provides as interfaces to the inbound adapters. Reasoning: - In the past only outbound ports where described. Use cases should be used directly. This was a pragmatic approach to reduce the effort of implementing interfaces whith the same signature as the implementation. But this differs from the idea of making the implementation transparent to the inbound adapters. Refs: devonfw#39
- Add inbound ports to the images - make services optional - Remove class names in adapters. This didn't really fit to the rest of the application. It did not become clear that *Listener could be postfixes for class names in java application. Therefore removed it here. - Mor options than client on inbound side, to make the varity of cases visible Ref: devonfw#39
The reason for the anemic domain models lies in two things. First of all are the domain models returned to the adapter. But business logic should not be moved outside. An additional mapping should be avoided. Furthermore in large scaled applications anemic domain models are much easier to handle, because the business logic is not spread across use cases, domain models and services. Making the applicaiton easier to understand
Removed the open comments. Added the multiple monoltih question as a open issue in github devonfw#42. Removed the records recommendation, as records cannot be inherited. That might lead to problems with large and complex domain models. Refs: devonfw#39
Refs: #82
Added review fixes. Renamed all outbound to outgoing and all inbound to incoming (according to SEAguide)
Add a project structure of an hexagonal architecture to devonfw to support new projects adapting this architecture style.