8 typo fixed
source | link

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, does not neeedneed to be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, does not neeed to be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, does not need to be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

7 wrong terms replaced
source | link

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, mustdoes not neeed to be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, must not be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, does not neeed to be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

6 typo fixed
source | link

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, must not be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendorwvendor without exposing them to your domain layer.

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, must not be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendorw without exposing them to your domain layer.

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design.

Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, must not be exactly what your third party library calls a document, so it could alternatively be a certain page range within the latter. If you follow that route, extracting the first page from a PDFDocument can be implemented internally just by setting the page range from "page 1 to page 1", without creating a new original "3rd party document object". The stamp operation then internally has to make use of that page range, as well as the final merge.

So I guess it should be possible to have both: a simple representation for PDFDocuments in your adapter layer, and the usage of internal optimizations provided by your library vendor without exposing them to your domain layer.

5 deleted 194 characters in body
source | link
4 added 100 characters in body
source | link
3 added 1 character in body
source | link
2 added 188 characters in body
source | link
1
source | link