Timeline for Ways to share DTO across microservices?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 21, 2022 at 11:31 | comment | added | Dherik | @Ayyappa can you elaborate more your question? My understanding of "DTO-Entity mapper" is libraries like MapStruct (for Java). | |
| Dec 21, 2022 at 11:26 | comment | added | Dherik | @julealgon a CountryCode is not something that are changed with much frequency, so it's not really a problem to have this as a shared library or even duplicated among the services, because will not make much difference for most cases. | |
| Nov 18, 2020 at 23:33 | comment | added | julealgon | What if among the DTOs there are a few enum classes? Some of the enums can be extremely general purpose, properly named and with comments. Duplicating all that work across multiple projects seems like a DRY violation to me. If the enumeration is stable enough, it should be shared some way, shouldn't it? Suppose for example there is a CountryCode enum, with every country code for all current countries in the world. Would it be wise to duplicate this too? | |
| Aug 8, 2020 at 6:29 | comment | added | Ayyappa | What about DTO-Entity mappers? Can't it be shared? DTO's can be automated by generating from the code generator using spec but mappers can't be. So what is the suggested approach? | |
| Mar 8, 2018 at 8:03 | audit | Low quality posts | |||
| Mar 8, 2018 at 8:04 | |||||
| Feb 26, 2018 at 12:02 | comment | added | Jonathan van de Veen | To clarify the essence of the answer, when developing microservices, each service should be developed as if they do not know about the other services, except for the actual contracts it may require. | |
| Feb 25, 2018 at 18:27 | comment | added | Laiv | Even a whole service might be delete causing no major problems to the whole system. Ideally. | |
| Feb 25, 2018 at 17:44 | comment | added | bdsl | Presumably then there's no reason not to copy the DTO source code directly from one project to another, as a one-off operation, although then any parts not required in the new project should probably be deleted. | |
| S Feb 20, 2018 at 17:13 | history | suggested | Yitzchok | CC BY-SA 3.0 | Fixed grammar issue |
| Feb 20, 2018 at 17:02 | review | Suggested edits | |||
| S Feb 20, 2018 at 17:13 | |||||
| Feb 20, 2018 at 11:19 | comment | added | Laiv | Duplicated DTOs (in different and very independent services) don't violate DRY. That's it. | |
| Feb 20, 2018 at 3:04 | vote | accept | foxtrotuniform6969 | ||
| Feb 20, 2018 at 3:04 | comment | added | foxtrotuniform6969 | Very much appreciated. This is really one of very few major concerns I have going forward. Not enough to keep me up at night, but enough to worry me. | |
| Feb 20, 2018 at 1:00 | history | answered | Dherik | CC BY-SA 3.0 |