SeedStack is an extensible solution that can be enriched with add-ons to provide new functionality or features. Writing an add-on is not a difficult task as it is very similar to writing an application but some rules and conventions must be obeyed. This guide will describe these rules and conventions.
Domain-Driven Design itself can be successfully applied in variety of software architectural styles. Some are very broad and tend to define every aspect of the system, others are more focused and try to address a specific demand. The business framework itself can adapt to several architectural styles. This documentation will focus on the traditional layered architecture from the Eric Evans DDD book, improved by the usage of the Dependency Inversion Principle.
Naming conventions JAR-level When relevant, modules provide their API in a separate sub-module suffixed with -specs in which case the corresponding module implementation is suffixed -core. This allows to implement classes using the API without activation. This is useful when designing reusable components. Besides, to provide a better separation of concerns, some modules are further split into optional sub-modules: seed-[module]-specs for the API and/or the SPI, seed-[module]-core for the main implementation, seed-[module]-[option] for an optional implementation module.
We recommend a well-defined package layout for organizing your business code according to the software architecture described above. The domain The root package for the domain layer is: [base.package].domain The domain can be composed of several sub-domains that can be specified as sub-packages: [base.package].domain.subdomain1 [base.package].domain.subdomain2 ... The domain package (or each sub-domain package if relevant) contains: A model package containing aggregates, each in its own package. An aggregate package contains The aggregate root along with other related entities and value objects, The factory interface if any, The repository interface if any, The aggregate policies if any.