Some thoughts about architecture overall

1. From class
To architecture
Marcin Hawraniak

2. About me
● Working @ Red-Sky
● CTO @ ChallengeMe.GG
● 10+ years of commercial programming
● Building stuff to solve problems :)

3. Disclaimer
● There are no solutions that solve all problems
● Presentation is on abstract level

4. Developer wants to code a class.
Class is a solution for a problem so Developer
seeks one...

5. Problem distillation

6. Source: http://serviceorientation.com/serviceorientation/service_composability

7. Source: http://serviceorientation.com/serviceorientation/service_composability

8. Source: http://serviceorientation.com/serviceorientation/the_need_for_service_orientation

9. Problem distillation
● This is not business layer only, applies to technical aspects as well!
● Business may benefit early due to smaller solutions being ready faster than all at
once
● Communicate with business to find critical ones - focus on them first

10. What helps to control size of a
problem/solution?

11. Domain Driven Design

12. Domain Driven Design
Source: Domain Driven Design Quickly

13. Source: Domain Driven Design Quickly

14. DDD - Bounded Context
● Logical barriers of the model that give solution to a problem
● Same entity across Bounded Contexts may have different names and properties
● Bounded Context may be considered as a logical boundary in monolith application or
Microservice
● Helps in non DDD environment too!

15. Source: “.NET Microservices: Architecture for Containerized .NET Applications”

16. Use case: Tournaments with schedule

17. Use case: Tournaments with schedule
● Tournaments should support multiple systems (single/double elimination, swiss, …)
● Matches are scheduled
● Created matches allow to play a game
Tournaments
Scheduled Matches

18. Use case: Tournaments with schedule
Assumptions:
● Platform already supports matches
Tournaments
Scheduled Matches
Matches

19. Use case: Tournaments with schedule
Business concerns:
● We may require scheduled matches without tournaments in the future
Tournaments Scheduled Matches Matches

20. Use case: Tournaments with schedule
Tournaments Scheduled Matches Matches
Tournaments with
scheduled
(business process)

21. Business process vs lower level components
Business process Lower level components
● Ties components together
● Controls the flow
● Use case naming convention in
code
● Business use case Bounded
Context
● Quite generic/reusable as a
component
● Component specific naming
convention in the code
● Local Bounded Context

22. Use case: Tournaments with schedule
Benefits
● Easier to split work across developers
● Ready to support new feature
● Reusability of components
● Less code in each component
● Very specific business requirements’ details not spoiling reusable components

23. All good but...

24. Time
Scope Quality

25. Following all principles not always possible
● Chasing perfection - endless refactoring
● “Better working than perfect”
● Almost everyone may give different solution for the same problem
● Write code in such way (decoupling) to limit scope of changes leaking outside of
given code scope while refactoring
● Be aware of what rules are being broken (SOLID)

26. When there is no time
● Assess price of technical debt and the risk involved
○ Is component critical?
○ Does current state introduces risks?
○ Is the code readable enough?
○ In case of refactoring, will I need to change code only within this single component?
○ How important is it for business?
○ How business will benefit by changing this in comparison to cost of change?
○ Does component follow project’s convention enough?
○ How business would benefit from current code despite its quality?
○ Will I be able to refactor it later?
● Negotiate scope
● Communicate!

27. Mechanical vs deep refactoring
● Mechanical refactoring usually is cheap and introduces low risk
○ Examples:
■ Renaming Classes / Interfaces
■ Code formatting
● Deep refactoring
○ Requires changing actual domain (may introduce new edge cases)
○ Within single Bounded Context introduces low to medium risk (unit tests)
○ Across many Bounded Contexts introduces medium to high risk (integration test)

28. Common closure principle
The classes in a package should be closed together against the same kinds of changes.
A change that affects a package affects all the classes in that package.
Source: “Principles of Package Design” by Matthias Noback

29. Classes grouped using Bounded Context.
Ideas how to structure the code?

30. Abstract of directory structure

31. Source: https://fideloper.com/hexagonal-architecture

32. Source: https://fideloper.com/hexagonal-architecture

33. Source: https://fideloper.com/hexagonal-architecture

34. Top directory tree
● Framework
○ Communication related (HTTP, Websocket, CLI, ACL, rate limiting, …)
● Application
○ Connects business logic with framework
○ Implement Domain interfaces (like database, API or other 3rd party libraries)
○ Transactions handling
○ Catches Domain Events (logging, queueing, sending email)
● Domain
○ Completely technology agnostic by using Interfaces
○ Contains Components and Shared Kernel

35. Component / Business process - example
● Entities
○ Entity1
○ Entity2
● Repositories
○ Entity1RepositoryInterface
○ Entity2RepositoryInterface
● Service
● Tests

36. Component / Business process - notes
● If Entity1 references lots of Entity2 (oneToMany)
○ Make separate repository for each Entity
○ Foreign keys are ok within Component
● Repositories
○ Generic methods (at least)
○ Performance optimized methods if needed (counting)
● Service
○ Calling methods changes state of Entity
● Tests
○ Unit tests

37. Component / Business process - notes
● Tracking - each component may track it’s own domain specific history changes
○ Consider tracking more than needed - business will ask soon about KPIs
○ To solve storage/performance issue implementation may use NoSQL
○ Tracking may be explicit (in domain) or implicit (via tracking dispatched events)
● Passing data to service methods
○ Simple types makes testing easier

38. Shared kernel - notes
● Components commonly used by other Components (Event Dispatcher, Base Entity
Classes, Traits, Scheduler)
● Changes may affect other Components

39. Components relation to other components
● Assigning Entity reference to Entity from other component
○ In most cases ID is enough (avoid foreign keys)
○ Referencing different kinds of Entities by storing Context Type and Context ID, example:
■ Type Match and Match ID
■ Type Tournament and Tournament ID

40. Relation on code level vs service level
● Code level
○ Single app instance
○ Higher level components may extend lower level components with plugins
○ Coupled code vs Dispatching Events
● Service level (SOA / Microservices)
○ No code sharing
○ Access only via API / Messaging

41. Technical components
● Do not mix low level technical components with Domain
● Naming basing on Context:
○ Image processing
○ Communication (Websockets / HTTP / Queue)
○ Domain Framework (ie Interfaces for Commands, Dispatcher)
○ Addition to 3rd party framework (Symfony / Laravel)

42. CQRS

43. Command Query Responsibility Segregation
Source: https://microservices.io/patterns/data/cqrs.html

44. What if I don’t have full CQRS?
● Commands will use Services from domain
● Queries
○ In simplest form may use existing Repositories from Components
○ Consider separate Repository Interface for Commands/Services and Queries
○ Keep adding counters / redundant data step by step avoid complex joins and speed up queries
○ Over time Query Repository may use more advanced solutions

45. Architectures

46. Source: https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658090(v%3dpandp.10)

47. Source: http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

48. Source: https://fideloper.com/hexagonal-architecture

49. Source:
https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexag
onal-onion-clean-cqrs-how-i-put-it-all-together/

50. My Class
● Is it technical, domain or connecting domain with framework?
● Is it for state change or reading?
● Is it generic or application/use case specific?
● Does it have state?
● Which properties are optimization purposes?
● What Bounded Contexts it should be aware of?

51. Summary
● Chosen approach depends on team’s experience, available time, project’s lifespan
● Seek for Bounded Context in non DDD components/layers too!
● Coupling within Component is good. Unnecessary coupling between Components is
bad.
● There are no strict rules, each team goes their own path
● Introduce new ideas in your project step by step
● Explore, make mistakes, improve

52. Resources
● https://www.infoq.com/minibooks/domain-driven-design-quickly
● https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/
● https://fideloper.com/hexagonal-architecture
● http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
● https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-i
t-all-together/

53. Questions?
● hawraniak@red-sky.pl
● Looking for challenges? rekrutacja@red-sky.pl

54. Thank you <3