This starter codebase will help to get workflow attendees to get started with Object Oriented Domain Modeling. OOP has been a sort of default paradigm in the Domain Modeling world for a long time so all of the resources we use to learn about Domain Modeling are usually already talking about Object Oriented Domain Modeling. As a result using OOP to model domains has lower friction and will require less explanation and "translation" of ideas.
This is a starting point for modeling the procurement domain with an object oriented style. There is a single starter use case to Create a new Purchase Order. This use case has a repository injected into it using the Dependency Inversion Principle.
There is a single starter entity for the Purchase Order that does nothing but generate an id for itself when it is constructed.
These rules are optional (especially in production code), but I recommend trying to stick to the object calisthenics rules. These are rules that are desinged for practice sessions like this - so I encurage you to try them out!
- Only One Level Of Indentation Per Method. Having too many levels of indentation in your code is often bad for readability
- Don’t Use The ELSE Keyword.
- Wrap All Primitives And Strings. encapsulate all the primitives within objects, in order to avoid the Primitive Obsession anti-pattern.
- First Class Collections. Any class that contains a collection should contain no other member variables.
- One Dot Per Line. Basically, the rule says that you should not chain method calls.
- Don’t Abbreviate. If you can’t find a decent name for a class or a method, something is probably wrong.
- Keep All Entities Small. No class over 50 lines and no package over 10 files.
- No Classes With More Than Two Instance Variables.
- No Getters/Setters/Properties.