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
+49-71Lines changed: 49 additions & 71 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,42 +1,42 @@
1
-
# practical-clean-ddd
1
+
# clean-architecture-dotnet
2
2
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.
3
+
"Everything should be made as simple as possible, but not simpler." - Albert Einstein
"Mọi thứ đều nên đơn giản, càng đơn giản càng tốt, nhưng không nên đơn giản hơn bản chất của nó." - Vietnamese translated
6
+
7
+
We know that, and that's a reason we publish these libraries and samples. These are distillations with all best practices, tips, and tricks, and whatever made us spend a lot of time struggling to solve.
8
+
9
+
In the end of our journey, we would like to give these simplified and effortless libraries and samples as a reward for you. Enjoy the Minimal Clean Architecture, Domain-driven Design Lite, CQRS Lite, and just enough Cloud-native patterns!
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.
91
+
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.
97
92
98
93
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.
99
94
100
95
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.
101
96
102
-

97
+

98
+
Reference to https://github.com/Sairyss/domain-driven-hexagon
99
+
100
+
# Project structure
101
+
102
+

103
+
104
+
## Project dependencies
105
+
106
+

103
107
104
108
## Core project
105
109
### Domain
106
110
107
-
TODO
108
-
109
-
### Repository
111
+
This contains all things to get start the project. Almost there are DDD-lite components just like Entity, AggregateRoot, Specification, Repository.
110
112
111
-
TODO
113
+
Assembly: N8T.Core.dll
112
114
113
115
## Infrastructure project
114
116
115
-
TODO
117
+
This is where some of component for Clean Architecture resides such as drivers (Entity Framework for PostgresDB, Authentication, Dapr Bus, MVC, Logging, Service Invocation with Dapr, Service Status model, Swagger with SwashBuckle, Transactional Outbox with Dapr, Tye configuration, Validation Model, OpenTelemetry components)
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
0 commit comments