start fixing some links and formatting

Author: hjwp

_posts/2017-09-07-introducing-command-handler.md

@@ -8,10 +8,9 @@ tags:
   - architecture
 ---
 
-The term DDD comes from the book by Eric Evans: "Domain-Driven Design: Tackling
-Complexity in the Heart of Software
-[https://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215]
-". In his book he describes a set of practices that aim to help us build
+The term DDD comes from the book by Eric Evans: ["Domain-Driven Design: Tackling
+Complexity in the Heart of Software"]([https://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215).
+In his book he describes a set of practices that aim to help us build
 maintainable, rich, software systems that solve customer's problems. The book is
 560 pages of dense insight, so you'll pardon me if my summary elides some
 details, but in brief he suggests:
@@ -37,17 +36,16 @@ they are caused by a lack of organisation in the codebase. In fact, the tools to
 solve these problems take up half of the DDD book, but it can be be difficult to
 understand how to use them together in the context of a complete system.
 
-I want to use this series to introduce an architectural style called Ports and
-Adapters [http://wiki.c2.com/?PortsAndAdaptersArchitecture], and a design
-pattern named Command Handler
-[https://matthiasnoback.nl/2015/01/responsibilities-of-the-command-bus/]. I'll
-be explaining the patterns in Python because that's the language that I use
+I want to use this series to introduce an architectural style called
+[Ports and Adapters](http://wiki.c2.com/?PortsAndAdaptersArchitecture),
+and a design pattern named
+[Command Handler](https://matthiasnoback.nl/2015/01/responsibilities-of-the-command-bus/).
+I'll be explaining the patterns in Python because that's the language that I use
 day-to-day, but the concepts are applicable to any OO language, and can be
 massaged to work perfectly in a functional context. There might be a lot more
 layering and abstraction than you're used to, especially if you're coming from a
 Django background or similar, but please bear with me. In exchange for a more
-complex system at the outset, we can avoid much of our accidental complexity
-[http://wiki.c2.com/?AccidentalComplexity]  later.
+complex system at the outset, we can avoid much of our [accidental complexity](http://wiki.c2.com/?AccidentalComplexity)  later.
 
 The system we're going to build is an issue management system, for use by a
 helpdesk. We're going to be replacing an existing system, which consists of an
@@ -83,7 +81,7 @@ issue.
 
 Okay, before we get to the code, let's talk about architecture. The architecture
 of a software system is the overall structure - the choice of language,
-technology, and design patterns that organise the code and satisfy our 
+technology, and design patterns that organise the code and satisfy our
 constraints [https://en.wikipedia.org/wiki/Non-functional_requirement]. For our
 architecture, we're going to try and stick with three principles:
 
@@ -212,7 +210,7 @@ skip ahead a little to a new command handler:
 class MarkIssueAsResolvedHandler:
     def __init__(self, issue_log):
         self.issue_log = issue_log
-        
+
     def __call__(self, cmd):
         issue = self.issue_log.get(cmd.issue_id)
         # the following line encodes a business rule
@@ -222,9 +220,9 @@ class MarkIssueAsResolvedHandler:
 
 This handler violates our glue-code principle because it encodes a business
 rule: "If an issue is already resolved, then it can't be resolved a second
-time". This rule belongs in our domain model, probably in the mark_as_resolved 
+time". This rule belongs in our domain model, probably in the mark_as_resolved
 method of our Issue object.
-I tend to use classes for my command handlers, and to invoke them with the call 
+I tend to use classes for my command handlers, and to invoke them with the call
 magic method, but a function is perfectly valid as a handler, too. The major
 reason to prefer a class is that it can make dependency management a little
 easier, but the two approaches are completely equivalent. For example, we could
@@ -258,7 +256,7 @@ However you structure them, the important ideas of commands and handlers are:
 
 Let's take a look at the complete system, I'm concatenating all the files into a
 single code listing for each of grokking, but in the git repository
-[https://github.com/bobthemighty/blog-code-samples/tree/master/ports-and-adapters/01] 
+[https://github.com/bobthemighty/blog-code-samples/tree/master/ports-and-adapters/01]
  I'm splitting the layers of the system into separate packages. In the real
 world, I would probably use a single python package for the whole app, but in
 other languages - Java, C#, C++ - I would usually have a single binary for each
@@ -294,7 +292,7 @@ class ReportIssueCommand(NamedTuple):
 
 
 # Service Layer
- 
+
 class ReportIssueHandler:
 
     def __init__(self, issue_log):

_posts/2017-09-08-repository-and-unit-of-work-pattern-in-python.md

@@ -8,8 +8,9 @@ tags:
   - architecture
 ---
 
-In the previous part [https://io.made.com/blog/introducing-command-handler/]  of
-this series we built a toy system that could add a new Issue to an IssueLog, but
+In the previous part
+([Introducing Command Handler]({% post_url 2017-09-07-introducing-command-handler %}))
+of this series we built a toy system that could add a new Issue to an IssueLog, but
 had no real behaviour of its own, and would lose its data every time the
 application restarted. We're going to extend it a little by introducing some
 patterns for persistent data access, and talk a little more about the ideas

_posts/2017-09-13-commands-and-queries-handlers-and-views.md

@@ -8,11 +8,11 @@ tags:
   - architecture
 ---
 
-In the first and second parts of this series I introduced the Command-Handler
-[https://io.made.com/blog/introducing-command-handler/]  and Unit of Work and
-Repository
-[https://io.made.com/blog/repository-and-unit-of-work-pattern-in-python/] 
-patterns. I was intending to write about Message Buses, and some more stuff
+In the first and second parts of this series I introduced the
+[Command-Handler]({% post_url 2017-09-07-introducing-command-handler %})
+and
+[Unit of Work and Repository patterns]({% post_url 2017-09-08-repository-and-unit-of-work-pattern-in-python %}).
+I was intending to write about Message Buses, and some more stuff
 about domain modelling, but I need to quickly skim over this first.
 
 If you've just started reading the Message Buses piece, and you're here to learn
@@ -21,11 +21,10 @@ after a bunch of stuff about ORMs, CQRS, and some casual trolling of junior
 programmers.
 
 What is CQS ?
-The Command Query Separation
-[https://martinfowler.com/bliki/CommandQuerySeparation.html]  principle was
-first described by Bertrand Meyer in the late Eighties. Per wikipedia
-[https://en.wikipedia.org/wiki/Command%E2%80%93query_separation], the principle
-states:
+The [Command Query Separation](https://martinfowler.com/bliki/CommandQuerySeparation.html)  principle was
+first described by Bertrand Meyer in the late Eighties. Per
+[wikipedia](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation),
+the principle states:
 
 every method should either be a command that performs an action, or a query that
 returns data to the caller, but not both. In other words, "Asking a question
@@ -41,14 +40,14 @@ class LightSwitch:
     def toggle_light(self):
         self.light_is_on = not self.light_is_on
         return self.light_is_on
-        
+
     @property
     def is_on(self):
         return self.light_is_on
 
 
 In this class, the is_on  method is referentially transparent - I can replace it
-with the value True or False without any loss of functionality, but the method 
+with the value True or False without any loss of functionality, but the method
 toggle_light  is side-effectual: replacing its calls with a static value would
 break the contracts of the system. To comply with the Command-Query separation
 principle, we should not return a value from our toggle_light  method.
@@ -72,8 +71,8 @@ data back out of our model? What is the equivalent port for queries?
 The answer is "it depends". The lowest-cost option is just to re-use your
 repositories in your UI entrypoints.
 
-@app.route("/issues") 
-def list_issues(): 
+@app.route("/issues")
+def list_issues():
     with unit_of_work_manager.start() as unit_of_work:
         open_issues = unit_of_work.issues.find_by_status('open')
         return json.dumps(open_issues)
@@ -99,10 +98,10 @@ and an email notification.
 @app.route('/issues/<issue_id>', methods=['DELETE'])
 def delete_issue(issue_id):
     logging.info("Handling DELETE of issue "+str(issue_id))
-    
+
     with unit_of_work_manager.start() as uow:
        issue = uow.issues[issue_id]
-         
+
        if issue is None:
            logging.warn("Issue not found")
            flask.abort(404)
@@ -113,7 +112,7 @@ def delete_issue(issue_id):
              smtp.send_notification(Issue.Deleted, issue_id)
           except:
              logging.error(
-                "Failed to send email notification for deleted issue " 
+                "Failed to send email notification for deleted issue "
                  + str(issue_id), exn_info=True)
        else:
           logging.info("Issue already deleted. NOOP")
@@ -138,11 +137,11 @@ class OpenIssuesList:
     def fetch(self):
         with self.sessionmaker() as session:
             result = session.execute(
-                'SELECT reporter_name, timestamp, title 
+                'SELECT reporter_name, timestamp, title
                  FROM issues WHERE state="open"')
             return [dict(r) for r in result.fetchall()]
-        
-        
+
+
 @api.route('/issues/')
 def list_issues():
     view_builder = OpenIssuesList(session_maker)
@@ -194,7 +193,7 @@ for assignee in task.assignees:
     assignee.manager.notifications.add(notification)
     assignee.notifications.add(notification)
     assignee.queues.inbox.add(task)
-       
+
 
 
 ORMs make it very easy to "dot" through the object model this way, and pretend
@@ -283,7 +282,7 @@ def report_issue(self):
     # they can be shared amongst several systems and are easy
     # to generate.
     issue_id = uuid.uuid4()
-    
+
     cmd = ReportIssueCommand(issue_id, **request.get_json())
     handler.handle(cmd)
     return "", 201, { 'Location': '/issues/' + str(issue_id) }

_posts/2017-09-19-why-use-domain-events.md

@@ -12,12 +12,9 @@ Nota bene: this instalment in the Ports and Adapters with Command Handlers
 series is code-heavy, and isn't going to make much sense unless you've read the
 previous parts:
 
- * Introducing Command Handler
-   [https://io.made.com/blog/introducing-command-handler/]
- * Repositories and Units of Work
-   [https://io.made.com/blog/repository-and-unit-of-work-pattern-in-python/]
- * Commands and Queries, Handlers and Views
-   [https://io.made.com/blog/commands-and-queries-handlers-and-views/]
+ * [Introducing Command Handler]({% post_url 2017-09-07-introducing-command-handler %})
+ * [Repositories and Units of Work]({% post_url 2017-09-08-repository-and-unit-of-work-pattern-in-python %})
+ * [Commands and Queries, Handlers and Views]({% post_url 2017-09-13-commands-and-queries-handlers-and-views %})
 
 Okay, so we have a basic skeleton for an application and we can add new issues
 into the database, then fetch them from a Flask API. So far, though, we don't