Q: Now what is the goal of this Business Software?
A: Right again: the core is about solving business problems.
So far so good. But is it easy to get a grip on the business problem and provide a proper solution? Probably everybody who ever tried to design a solution for a business problem will agree that this is not an easy task at all. No matter if we develop standard software (as we do at SAP), if we are a partner providing Add-ons ora customer trying to design an extension, we are convinced that the hardest part is to achieve a proper understanding of the business problem.
The challenge and how to deal with it
Why is it so hard to provide a solution for a business problem? From our experience the main issue is to have a proper understanding of the problem mainly due to the business experts speaking a different “language”, the one of their business domains. But hey … are we the first that need to deal with this?By no means!And there is an approach that helps you especially with this task (and even more): Domain-driven Design, amethodology that was started by Eric Evans with his book “Domain-Driven Design: Tackling Complexity in the Heart of Software” in 2003 (yes that was 19 years ago) is a well-fitting approach for this.
The focus of the collected resources lies on the term “curated”: There are lots of useful high-quality collections about Domain-Driven Design, but it is often hard to find a point where to start. We struggled with that and maybe we are not the only ones. We therefore thought it a good idea to share our approach on how to learn Domain-Driven Design with you, the SAP community.Consequently, you find learning paths that we use to get started with Domain-Driven Design. And even if you are already experienced but want to see if there is more to learn? We got you covered with expert content around topics like Domain-Driven Design and legacy systems.
As the resources are available as a public GitHub repository, we would love to hear your feedback and get contributions of further resources that add value to the repository via the established GitHub mechanisms like issues and discussions.
Last but not least: If you want to walk fast, walk alone. If you want to walk far, walk together So big thanks to the partners in crime: p.kostyra, dhem and Philipp Stotz)
P.S. One more thing before you go. Domain-Driven Design currently has a lot of attention when designing microservices. Do not make the wrong conclusions from that: Domain-Driven Design is technology-agnostic. No matter where your technology decisions will lead you, Domain-Driven Design always helps you to achieve a well-designed solution for your business problem.