vmptk / cp.orderly

Cp.Orderly

An Expieremental, Clean, Extensible, Event-Driven & Scalable
Goods Ordering Software Architecture

---

1. Modules/Services

All the following modules can be deployed, and managed seperately but they were put the same repository for the sake of convinience.

ID	Name	Description
CS	Customer Service	Customers functionalities
SHS	Shop Service	Shop functionalities
OS	Order service Service	Orders management functionalities
PS	Payment service	Payments functionalities
IM	Infrastructure module	Contains concrete infrastructure client's implementations and consistency and long running transactions handlers
COM	Commons module	contains re-usable and generic domain entities, events, exceptions, value objects and repositories
LOC	Local development	consists of all the needed to-be-provisioned environments for local development porposes

2. Documentation

For more detailes about how the overall system is interacting together, refer to 1.Architecture.md in docs where the system's documentation resides. Service specific implementation and setup details can be found in the the respective service's README.md.

3. Building

For more details about the building process, refer to the local-development.md

4. Contribution Guidelines

4.1 Commits Guidelines

To ease up the process of versioning the software based on the kind of changes/features being applied/added, this repository is using conventional commits for its git commit messages.

The following keywords can be used:

feat, fix, test, build, perf, docs, refactor / ref, chore

Commit keywords can include one or more scopes for the specic module being modified. E.g.

feat(CS, SHS): ..Commit message goes here..
ref(OS): ...

4.2 Branches rules

Every new feature/improvement is push with a new branch name is prefixed with its purpose of creation preferable conventional-commit-keyword/brief-title.
Main branch is protected and requires pull request and an approval of at least one reviewer. branches are squashed and rebased.

4.3 CI Checks

Pull requests can't be merged without meeting the requirements mentioed above, plus the linting, testing, and building jobs which should be tested during development.

For checking and applying the linting changes the project is relying on Spotless.

4.3 Re-usable module builds compponents

...

Literature, references & resources

• The Clean Architecture - Clean Coder Blog. (2012, August 13) - Book
• Vernon, V. (2016). Domain-driven Design Distilled. Addison-Wesley Professional.
• Vernon, V. (2013). Implementing Domain-driven Design. Pearson Education.
• Kleppmann, M. (2017). Designing Data-intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems.
• Evans, E., & Evans, E. J. (2004). Domain-driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.
• Garcaa-Molina.H, Salem. K. - Sagas
• Cockburn, A. (n.d.). Hexagonal architecture. Alistair Cockburn
• Newman, S. (2019). Building Microservices: Designing Fine-Grained Systems. O’Reilly Media.
• Cockburn, A. (2001). Writing Effective Use Cases. Agile Software Development Series.
• H. (2020). DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together.
• Ford, N., Richards, M., Sadalage, P., & Dehghani, Z. (2021). Software Architecture: the Hard Parts
• Martinez, P. (2022, January 6). Hexagonal Architecture, there are always two sides to every story. Medium.

---