Skip to content

Instantly share code, notes, and snippets.

@sizovs

sizovs/gist:57a88afceb7f69f00b5e6fbd8e0832cd

Last active May 31, 2021 08:30
Show Gist options
  • Save sizovs/57a88afceb7f69f00b5e6fbd8e0832cd to your computer and use it in GitHub Desktop.
Save sizovs/57a88afceb7f69f00b5e6fbd8e0832cd to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.md

Playtech Wrap-up

Links

LinkedIn certificates

Congrats! : )

Awesome books

  • Growing Object-Oriented Software Guided by Tests — Testing and TDD book
  • TDD: TDD by Example (Kent Beck) — TDD book
  • Secure by Design (Dan Bergh Johnsson, Daniel Deogun) — Software Design book
  • Java Application Architecture (Kirk K.) — Architecture book
  • Patterns of Enterprise Application Architecture – Architecture book
  • Clean Code — coding book
  • Head First Design Patterns (2nd edition) – Software Design book
  • Domain-Driven Design (Vaughn Vernon) – Software Architecture and Design book
  • Elegant Objects – OOP book, explains CQS well
  • The Software Craftsman – inspiration to become a better programmer :-)
  • The Clean Coder – inspiration to become a better programmer :-)

Java libs

Videos:

Not mentioned in slides

  • Marker interface
  • The stepdown rule (explained well in Clean Code book)
  • Don't let @Entities escape the transaction boundary. Always return DTOs.
  • Spring "sees" static nested classes.

Things we didn't have time and energy to cover

  • Day I: more or less 100% coverage
  • Day II: Managing dependencies between packages and why it matters. You can watch my old but still relevant video from XPDays conference in Ukraine. It's in Russian. English version is available too, but it's not that good IMHO. Or is it? :-)
  • Day II: Unit and acceptance testing. Slides are pretty self-explanatory.
  • Day II: Validation. Nothing particularly exciting here – just use Bean Validator to validate data classes. And remember that good objects are secure by design, t.i. objects should fail fast if you provide some falsy data; Even better – they shouldn't allow you to provide falsy data thanks to strong types. For example:
class Customer {
  Customer(UniqueEmail email) {
    this.email = email;
  }
}

class UniqueEmail {
  UniqueEmail(String uncheckedEmail, Uniqueness uniqueness) {
    checkArgument(uniqueness.isGuaranteed(uncheckedEmail), "Email {} is not unique", uncheckedEmail);
    this.email = uncheckedEmail;
  }
}

interface Uniqueness {
  boolean isGuaranteed(String email);

  @Component
  class AmongUsers implement Uniqueness {
    
    AmongUsers(UserRepository userRepository) {
      this.userRepository = userRepository;
    } 


    @Override
    public boolean isGuaranteed(String email) {
      return !userRepository.existsByEmail(email);
    }
  }
}
  • Day II: Aggregate roots. Software architecture best practices suggest that we should only create Repositories for Aggregate Roots. For example, BankAccount "owns" a collection of Transactions and controls access to them. So, Bank Account is an Aggregate Root. So our system should have one repository – BankAccountRepository, and never provide a separate repository for Transactions. Why? Check out the slides here: https://sizovs.net/jninja/part_2.html#86. For more explanation, read DDD book.
  • Day II: Transactional Outbox Pattern. Good explanation here: https://microservices.io/patterns/data/transactional-outbox.html

Let's stay connected!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment