Designing systems architecture corresponding to business needs in long future is like a reading tea leaves. There is no common way to design systems. Making decision to start project with microservices may make refactoring much harder and introduce too much complexity in the infrastructure layer and finally slow down development. However maintaining a monolith is a tough nut to crack. Let’s see how to build a system starting from well organized monolith with well marked technical and business scopes that enables to make a decision in with way it should be decomposed and how to deliver it. Strategic and tactical techniques from Domain-Driven Design and Hexagonal Architecture will be used. I will show you how to monitor accidential complexity using different tools during CI. I invite you if you are interested in building systems with complex business domains.

1. Pragmatic Monolith-First
easy to decompose, clean architecture
Piotr Pelczar
Gliwice 2017, Spread IT

2. Let’s design a system
• Several different products
• Multi Channel

3. System Architecture - Case
Accounts DepositsLoans

4. System Architecture - Case
Product API
GUI
Channel 1
GUI
Channel 2
• Simple Split-Architecture (GUI + backend)

5. System Architecture - Case
Accounts DepositsLoans

6. Business makes money
and want to scale
• Cross-sell

7. System Architecture - Case
Accounts DepositsLoans

8. System Architecture - Case
Accounts Loans

9. System Architecture - Case

10. System Architecture - Solution 1
Accounts Loans
Event Bus
Loans’
• Event-Driven + data duplication

11. System Architecture - Solution 2
Accounts
Repo
Loans
Accounts
Sales Process
• Refactor – move functionality to another module

12. System Architecture - Solution 2
Accounts
Repo
Loans
Repo
Accounts
Sales Process
Loans
Sales Process
• And more refactor…

13. Business makes Cross-sell
and want to scale
• Sell next type of Loan

14. “We want the same process.”

15. “… almost the same process, but…”

16. System Architecture - Case
Accounts
Repo
Loans
Repo
Loans
Sales Process
Dep
#1
Dep
#2
Dep
#3

17. System Architecture - Solution 1
Accounts
Repo
Loans
Repo
Loans
Sales Process
Dep
#1
Dep
#2
Dep
#3
Dep
#4
Dep
#5
• if, if, if, if
• strategy pattern (hidden if), chain of responsibility
• more dependencies

18. System Architecture - Solution 2
Loans
Sales Process
Dep
#1
Dep
#2
Dep
#3
Dep
#4
Dep
#5
• Design new process and bring some stuff to common
The Next one Loan
Sales Process
C
#1
C
#1
C
#1Commons:

19. Is it good decision?

20. Accounts Loans
…or this coupling is acceptable?
Can we assume that it is essential complexity
not accidental complexity?

21. Piotr Pelczar
Java, Groovy, node.js, PHP
11 yrs exp

22. We are making mistakes
Let’s prepare for them better

23. Microservices hype
We know benefits
We know drawbacks
One Bounded Context = 1 µS
Do we split properly? Do we understand Business?

24. Why not Microservices at the beginning?
• YAGNI
• True: Hard to scale poor designed successful software
• But it is better than have failed software but well designed
• You need to be agile at the beginning
• Works good only with well separated Bounded Contexts
• You have to learn domain first
• Refactoring in monolith is much simpler than in microservices
https://martinfowler.com/bliki/MonolithFirst.html

25. https://zeroturnaround.com/rebellabs/developer-productivity-report-2017-why-do-you-use-java-tools-you-use/

26. Monolith-First Architecture
Manifest:
• Build well-managed complexity monolith
• Easy to refactor (move between packages)
• Enables quick pivots in Domain Modeling
• Exposes ready to peel-off edges into microservices
Idyll?

27. Monolith-First Architecture
For:
• Long-living components (many projects)
• with Complex domain (no CRUD)

28. 1. Well done high-level packaging

29. 1. Well done high-level packaging
• Open the app folder
and can easily recognize what it is about

30. 1. Well done high-level packaging
• Packaging by technical layer = Monoloth RIP
• More than one Bounded Context in each layer = cannot split them

31. 1. Well done high-level packaging
Packaging by business scopes/Bounded Context = easy to split
com.acme.SERVICE-NAME.BOUNDED-CONTEXT.*

32. 2. Know your domain

33. 2. Know your domain
Modeling - DDD gives us tools:
• Tactical: (how to organize code)
• Aggregates, Value Objects, Repositories, Events
• Application Services, Domain Services (transforming data, integration)
• Strategic: (how to map and discover domain)
• Problem mapping
• Bounded Contexts

34. 2. Know your domain

35. 2. Know your domain
Event Storming – reveal domain by asking “what happened? when?”
Alberto Brandolini
https://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design

36. 2. Know your domain - DDD
"Software development is a learning process;
working code is a side effect."
In monolith we can start with:
• Rich domain
• Pilled-off bounded contexts (high level packages)

37. 3. Encapsulate the domain
(Clean Architecture and Usecases)

38. 3. Encapsulate the domain
• On top-level packages expose what application do
• not how it is devlivered
• Use Case is Application Service
pattern from DDD
It orchestrates the domain

39. 3. Clean architecture
https://8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html

40. @Service
public class CreateScheduleUC {
@Transactional
public void createSchedule(CreateScheduleCommand command, CreateScheduleResult result) {
ScheduleId newScheduleId = scheduleRepository.generateNextId();
ProgrammeId programmeId = ProgrammeId.of(command.getProgrammeId());
final Schedule newSchedule = Schedule.create(
newScheduleId,
programmeId
);
scheduleItemsMapper.mapItemsToDomain(newSchedule, command.getItems());
scheduleConstraintsMapper.mapConstraintsToDomain(newSchedule, command.getConstraints());
scheduleRepository.save(newSchedule);
result.success(newScheduleId.getId());
}
}

41. 3. Clean architecture
https://8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html

42. 3. Clean architecture
https://8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html

43. 3. Clean architecture
https://8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html

44. @Service
public class FindScheduleForDayUC {
@Data
@Builder
public static class ScheduleForDayCommand {
private final String programmeId;
private final LocalDate day;
}
public interface ScheduleForDayResult {
void success(Schedule schedule);
void notExists();
}
public void findScheduleForDay(ScheduleForDayCommand command,
ScheduleForDayResult result) {
// ...
result.notExists();
// ...
result.success( ... );
}
}

45. @Controller
@RequestMapping("/schedule")
class FindScheduleForDayController {
@GetMapping(value = "/forDay/{programmeId}/{day}")
@ResponseBody
@ApiResponses({
@ApiResponse(code = 200, message = "", response = ScheduleDto.class),
@ApiResponse(code = 404, message = ""),
})
public ResponseEntity<?> createSchedule(@RequestParam("programmeId") String
@RequestParam("day") @DateTimeFormat
ScheduleForDayCommand command = ...
FindScheduleForDayResponseBuilder responseBuilder ...
findScheduleForDayUC.findScheduleForDay(command, responseBuilder);
return responseBuilder.toResponse();
}
}

46. 3. Clean architecture
UI
Business Logic
DAO I/O …
Business Logic
Domain
GUI DAO I/O

47. 3. Clean architecture
https://8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html

48. 4. Make gaps in domain
Port and Adapters
aka Hexagonal Architecture

49. 4. Make gaps in domain
• Ports (red)
• Adapters (blue)
• Out
• In
• I like “delivery” instead of
“in adapters”
http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html

50. 4. Make gaps in domain
• Separates domain from dependencies
• Database
• Another Bounded Context
• Domain Services can map foreign domain
to our domain
• Forum Author instead of User
• Product parameters instead of Product from
catalogue
http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html

51. 5. Integrate Bounded Contexts

52. 5. Integrate Bounded Contexts
• Integrate via
Ports -> Adapters ->
referring to Usecases
• Almost Microservices!
http://www.natpryce.com/articles/images/ports-and-adapters-acceptance-testing.png

53. But we live in monolith…
and easy to make some unwanted
dependencies

54. 6. Manage Complexity

55. 6. Manage Complexity
http://www.structure101.com/

56. 6. Manage Complexity

57. 6. Manage Complexity
• Structure 101
• Java
• PHP
• Socomo Maven Plugin
• Java
• Another tools?

58. # prevent cyclic dependencies
check acyclicCompositionOf com.acme.someservice
[usecase] = com.acme.someservice.*.usecase.*
[domain] = com.acme.someservice.*.domain.*
[adapter] = com.acme.someservice.*.adapter.*
[delivery] = com.acme.someservice.*.delivery.*
# domain is independent of usecase
check [domain] directlyIndependentOf [usecase]
check [delivery] directlyIndependentOf [dziedzina]
# delivery constraints
check [usecase] directlyIndependentOf [delivery]
check [adapter] directlyIndependentOf [delivery]
check [domain] directlyIndependentOf [delivery]
# only heagonal architecture structure
check deny *
check allow com.acme.someservice.*.usecase.*
check allow com.acme.someservice.*.domain.*
check allow com.acme.someservice.*.adapter.*
check allow com.acme.someservice.*.delivery.*
# except technical packages
check allow com.acme.someservice.technical.*

59. 7. You are ready to peel-off edges

60. 7. Peel-off edges
1. Move whole package to another service
• add delivery layer only
2. Change Use Cases invocations in Adapters to RPC

61. 7. Peel-off edges
public class AuthorFromUserService implements AuthorProvider {
public Author getAuthor(String nickname) {
User user = someUsecase.getUserByUsername(nickname);
Author author = //...
return author;
}
}
Old Use Case invocation:

62. 7. Peel-off edges
public class AuthorFromUserService implements AuthorProvider {
interface UserService {
@RequestLine("GET /users/{username}")
User getUserByUsername(@Param("username") String username);
}
public Author getAuthor(String nickname) {
User user = userService.getUserByUsername(nickname);
Author author = //...
return author;
}
}

63. Monolith-First Architecture
1. Well done packaging
2. Know your domain (strategic and tactic DDD)
3. Encapsulate the domain (Clean Architecture and Usecases)
4. Make gaps in domain (Port and Adapters)
5. Integrate Bounded Contexts
6. Manage complexity (by CI tools)
7. You are ready to peel-off edges

64. We are making mistakes
Let’s prepare for them better

65. Monolith-First Architecture
For:
• Long-living components (many projects)
• when is a good time to peel-off?
• with Complex domain (no CRUD)

66. Monolith-First Architecture
• Many buzzwords?
These patterns already exists
there name is “interfaces”
here they are structured

67. Thanks! Q&A
http://doineedbackup.com/customer-acquisition-channels-for-saas/

68. https://highspark.co/how-to-end-a-presentation/
Thanks! Q&A