From 99f4691f1ab834fc1a55c28c743c79c44bbe9ecf Mon Sep 17 00:00:00 2001 From: Mark Seemann Date: Thu, 25 Jul 2024 20:29:54 +0200 Subject: [PATCH] Prepare article for publication --- ...5-three-data-architectures-for-the-server.html} | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) rename _posts/{2024-07-24-three-data-architectures-for-the-server.html => 2024-07-25-three-data-architectures-for-the-server.html} (95%) diff --git a/_posts/2024-07-24-three-data-architectures-for-the-server.html b/_posts/2024-07-25-three-data-architectures-for-the-server.html similarity index 95% rename from _posts/2024-07-24-three-data-architectures-for-the-server.html rename to _posts/2024-07-25-three-data-architectures-for-the-server.html index 017cc223..fa182575 100644 --- a/_posts/2024-07-24-three-data-architectures-for-the-server.html +++ b/_posts/2024-07-25-three-data-architectures-for-the-server.html @@ -2,7 +2,7 @@ layout: post title: "Three data architectures for the server" description: "A comparison, for educational purposes." -date: 2024-07-24 10:52 UTC +date: 2024-07-25 18:30 UTC tags: [Article Series, Architecture] image: "/content/binary/flowchart-with-choice.png" image_alt: "A flowchart diagram, now with three options available from the decision shape." @@ -23,7 +23,7 @@ Even so, the underlying idea is that there are better and worse ways to solve problems. In software architecture too. It follows that you should choose the better solution.

- How to do this requires skill and experience. When planning a good software architecture, an important consideration is how it'll handle future requirements. This seems to indicate that an architect should be able to predict the future in order to pick the best architecture. Which is, in general, not possible. Predicting the future is not the topic of this article. + How to do that requires skill and experience. When planning a good software architecture, an important consideration is how it'll handle future requirements. This seems to indicate that an architect should be able to predict the future in order to pick the best architecture. Which is, in general, not possible. Predicting the future is not the topic of this article.

There is, however, a more practical issue related to the notion of using the right tool for the job. One that we can address. @@ -82,7 +82,7 @@

  • Using only a Domain Model to persist restaurant table configurations

    • - As the titles suggest, all three examples will attempt to address the same problem: How to persist restaurant table configuration for a restaurant. The scenario is the same as already outlined in the article Serialization with and without Reflection, and the example code bases also attempt to follow the external data format of those articles. + As the titles suggest, all three examples will attempt to address the same problem: How to persist restaurant table configuration for a restaurant. The scenario is the same as already outlined in the article Serialization with and without Reflection, and the example code base also attempts to follow the external data format of those articles.

    Data formats # @@ -140,7 +140,7 @@

    Comparisons #

    - REST APIs are the kind of application where data representation flexibility is most likely to be an issue. Thus, that only one of the three alternative architectures is able to exhibit enough expressive power in that dimension doesn't disqualify the other two. Each come with their own benefits and drawbacks. + A REST API is the kind of application where data representation flexibility is most likely to be an issue. Thus, that only one of the three alternative architectures is able to exhibit enough expressive power in that dimension doesn't disqualify the other two. Each come with their own benefits and drawbacks.

    @@ -215,10 +215,10 @@

    The book is, for that reason, light on .NET-specific details. Instead, I published an article that collects all the interesting .NET things I ran into while writing the book.

    - Not so here. The three articles cover enough ASP.NET particulars that readers that don't care about that framework are encourages to skim-read. + Not so here. The three articles cover enough ASP.NET particulars that readers who don't care about that framework are encouraged to skim-read.

    - I've developed the three examples as three Git branches of the same repository. The code is available upon request against a small support donation of 10 USD (or more). If you're one of my regular supporters, you have my gratitude and can get the code without further donation. Send me an email in both cases. + I've developed the three examples as three branches of the same Git repository. The code is available upon request against a small support donation of 10 USD (or more). If you're one of my regular supporters, you have my gratitude and can get the code without further donation. Send me an email in both cases.

    Conclusion # @@ -227,7 +227,7 @@

    There's more than one way to organize a code base to deal with data. Depending on context, one may be a better choice than another. Thus, it pays to be aware of alternatives.

    - In the next articles in this article series, you'll see three examples of how to deal with persistent data from a database. In order to establish a baseline, the first covers the well-known Ports and Adapters architecture. + In the remaining articles in this series, you'll see three examples of how to deal with persistent data from a database. In order to establish a baseline, the first covers the well-known Ports and Adapters architecture.

    Next: Using Ports and Adapters to persist restaurant table configurations.