You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+36-33Lines changed: 36 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,20 +2,13 @@
2
2
3
3
The practical repository uses coolstore domain which is mainly borrowed from `https://github.com/zkavtaskin/Domain-Driven-Design-Example` to demonstrate how to apply Domain Driven Design seamlessly with Clean Architecture.
4
4
5
+
## Show your support
5
6
6
-
# Business Usecases
7
-
8
-

9
-
10
-
# High level context
11
-
12
-

13
-
14
-
# ERD
7
+
If you **cannot give a star**:star: for `practical-clean-ddd` repository, **try it again**!
15
8
16
-

9
+
Why? Because it doesn't only **help strengthen our .NET community** but also **helps to improve cloud-native apps development on the .NET platform**. Thank you very much :+1:
Domain-driven Design demonstrates it can help the business tidy and organized in many years. But it is hard to approach and use, we need to make it easier to use in the real project when we get started.
52
57
53
58
Clean Architecture helps the project structure easier to refactor and evolve in medium and big projects. Especially in the Microservice world, we always want to do and try with a lot of time in the project lifetime.
54
59
55
60
Clean Domain-driven Design is a collection of basic building blocks and project structure to help we get starting the project with less code boilerplate and effortless. We focus on the Microservice approach of how can we organize code, the project with the monorepo approach, and you can use it for modular monolith project as well.
61
+
62
+

63
+
56
64
## Core project
57
65
### Domain
58
66
@@ -70,9 +78,6 @@ TODO
70
78
71
79
TODO
72
80
73
-
## Api project
74
-
75
-
TODO
76
81
# Public CRUD interface
77
82
78
83
In medium and large software projects, we normally implement the CRUD actions over and over again. And it might take around 40-50% codebase just to do CRUD in the projects. The question is can we make standardized CRUD APIs, then we can use them in potential projects in the future? That is in my mind for a long time when I started and finished many projects, and I decide to take time to research and define the public interfaces for it as below
@@ -83,11 +88,19 @@ In medium and large software projects, we normally implement the CRUD actions ov
0 commit comments