The document discusses software architecture and design principles for organizing code into classes and components. It recommends using domain-driven design principles like bounded contexts to logically separate code and control the scope of changes. Specific approaches are suggested like using hexagonal architecture with separate domains, applications, and frameworks. The document also discusses balancing principles with pragmatism like avoiding perfection to get working code faster and managing technical debt.

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