Documentation
¶
Overview ¶
Package internal is one of two magical Go package identifiers. Basically, Go has no real package hierarchy. However, using "internal", only packages sharing the same root package, can import from internal. This is very useful to disallow public identifiers to be imported from other modules, similar to how Java modules work with the "exports" keyword. Keep in mind, that any go-module can be imported by any from your other go modules, which may be good or evil. For example, if you want to couple on a kind of shared kernel, you may define them in this module outside of the internal package, but mind your own backwards-compatibility guidelines.
Logically, this internal package represents the "super" domain of all contained bounded contexts.
In conclusion, we recommend to put everything into internal, to avoid a direct coupling between domain-driven applications. Communication and protocols must be made explicitly and independent of the actual code.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
Package app contains a package per cmd application, which contains the according dependency injection layer (DI).
|
Package app contains a package per cmd application, which contains the according dependency injection layer (DI). |
|
Package helloworld is a very small domain core without any I/O adapters, so its fine to just put it right into the bounded context folder!?
|
Package helloworld is a very small domain core without any I/O adapters, so its fine to just put it right into the bounded context folder!? |
|
Package invoicing is an empty unidiomatic package, which represents the bounded context of invoicing.
|
Package invoicing is an empty unidiomatic package, which represents the bounded context of invoicing. |
|
domain
Package invoicing contains the domains core and use cases (domain layer).
|
Package invoicing contains the domains core and use cases (domain layer). |
|
domain/positions
Package positions has been introduced because the domain model has become to large, so we break into smaller and more independent parts.
|
Package positions has been introduced because the domain model has become to large, so we break into smaller and more independent parts. |
|
domain/receiver
Package receiver has been introduced because the domain model has become to large, so we break into smaller and more independent parts.
|
Package receiver has been introduced because the domain model has become to large, so we break into smaller and more independent parts. |
|
postgresql
Package postgresql contains the domains repository implementations for postgresql.
|
Package postgresql contains the domains repository implementations for postgresql. |
|
rest
Package rest provides the rest presentation layer.
|
Package rest provides the rest presentation layer. |
|
s3
Package s3 contains the domains repository implementations for s3 blob storage.
|
Package s3 contains the domains repository implementations for s3 blob storage. |
|
web
Package web contains the web presentation layer.
|
Package web contains the web presentation layer. |
|
Package pkg contains implementations which are totally project independent and could possibly be extracted into standalone modules.
|
Package pkg contains implementations which are totally project independent and could possibly be extracted into standalone modules. |
|
Package sys contains infrastructure implementations which are project related (see also pkg package) but not specific for any bounded context.
|
Package sys contains infrastructure implementations which are project related (see also pkg package) but not specific for any bounded context. |
|
logging
Package logging provides the shared foundational/infrastructure implementation of common logging functions.
|
Package logging provides the shared foundational/infrastructure implementation of common logging functions. |
|
version
Package version provides some injected build time information.
|
Package version provides some injected build time information. |