4 ms·

Domain-Driven Design – art of writing a good code (production ready example)

11 points by tlandeka 4y ago

vmaurin 4y ago
While skimming over the repo, I am seeing a couple of warnings that indicate leaking abstraction/boundaries : * there are imports for Spring in the domain code (is Spring part of your domain?) * you are using a mock framework in some domain tests Also I am not sure I understand the "domain" and "ddd" packages. I am a huge supporter of splitting a "domain" package from a "application" package like you did, but then not sure where the ddd stands
- tlandeka 4y ago
  Q: there are imports for Spring in the domain code (is Spring part of your domain?) A: At only one place in order to be easy to replace it. I followed Vaugh Vernon example of mixing it: https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_identityaccess/src/main/java/com/saasovation/identityaccess/domain/model/DomainRegistry.java https://github.com/VaughnVernon/IDDD_Samples/blob/master/idd... Q: You are using a mock framework in some domain tests A: Yes. Can you write some pros/cons regarding to this. "domain" is real domain that contains business logic, "ddd" should be extracted to a common library (according to this example https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_common/src/main/java/com/saasovation/common https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd... and this one https://github.com/dddshelf/ddd https://github.com/dddshelf/ddd)
Sankozi 4y ago
Observations after briefly checking the code: - KISS and YAGNI rules are broken frequently - abuse of inheritance that makes even trivial classes harder to read - some usage of boxed types feels incorrect, if null is meaningful it should at least have some comment - confusing packages (like .ddd.domain vs .domain), would be nice to document what packages mean in readme
- tlandeka 4y ago
  "domain" is real domain that contains business logic, "ddd" should be extracted to a common library (according to this example https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd... and this one https://github.com/dddshelf/ddd https://github.com/dddshelf/ddd) Regarding to other issues, could you add little bit more concrete details just to check and consider possible solutions.
  - beaker52 4y ago
    DDD isn't about libraries, CQRS, event sourcing, microservices or k8s.
    - tlandeka 4y ago
      I followed the examples from the books. But let's say, my idea is to use that "boilerplate" code on other projects and not broke the DRY principle, I would rather extract that piece of code to be reusable.

11 points by tlandeka 4y ago

While skimming over the repo, I am seeing a couple of warnings that indicate leaking abstraction/boundaries : * there are imports for Spring in the domain code (is Spring part of your domain?) * you are using a mock framework in some domain tests Also I am not sure I understand the "domain" and "ddd" packages. I am a huge supporter of splitting a "domain" package from a "application" package like you did, but then not sure where the ddd stands

tlandeka 4y ago
Q: there are imports for Spring in the domain code (is Spring part of your domain?) A: At only one place in order to be easy to replace it. I followed Vaugh Vernon example of mixing it: https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_identityaccess/src/main/java/com/saasovation/identityaccess/domain/model/DomainRegistry.java https://github.com/VaughnVernon/IDDD_Samples/blob/master/idd... Q: You are using a mock framework in some domain tests A: Yes. Can you write some pros/cons regarding to this. "domain" is real domain that contains business logic, "ddd" should be extracted to a common library (according to this example https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_common/src/main/java/com/saasovation/common https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd... and this one https://github.com/dddshelf/ddd https://github.com/dddshelf/ddd)

Sankozi 4y ago

Observations after briefly checking the code: - KISS and YAGNI rules are broken frequently - abuse of inheritance that makes even trivial classes harder to read - some usage of boxed types feels incorrect, if null is meaningful it should at least have some comment - confusing packages (like .ddd.domain vs .domain), would be nice to document what packages mean in readme

tlandeka 4y ago
"domain" is real domain that contains business logic, "ddd" should be extracted to a common library (according to this example https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd... and this one https://github.com/dddshelf/ddd https://github.com/dddshelf/ddd) Regarding to other issues, could you add little bit more concrete details just to check and consider possible solutions.
- beaker52 4y ago
  DDD isn't about libraries, CQRS, event sourcing, microservices or k8s.
  - tlandeka 4y ago
    I followed the examples from the books. But let's say, my idea is to use that "boilerplate" code on other projects and not broke the DRY principle, I would rather extract that piece of code to be reusable.