{CodingBlocks}.NET

iTunes Spotify PlayerFM Overcast Podchaser Pocket Casts iHeartRadio YouTube feed LinkedIn Twitter Facebook Reddit

Navigation

Software Architecture – What is Supple Design?

By 5 Comments

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

More Domain Driven Design talk this week: Supple Design, Declarative(ish?) Programming, and Ohio Envy.

Sponsors

Start Slack’ing Now.

We’re so happy you’ve found us and now it’s time to become a part of the community. Head to http://www.codingblocks.net/slack to join in on the fun today.

Survey says …

You have 4 near identical job applicants (quadriplets) - they differ only in how they learned to code. Who do you hire?
vote
×

News

Assertions

  • Need ability to understand the meaning of a design without digging into the implementation
    • Intention revealing interfaces help here
  • Assertions describe state – NOT PROCEDURES
  • They make side effects explicit
  • State post-conditions from operations and invariants of classes and the aggregates
    • Write these as Unit Tests if the programming language doesn’t support assertions
    • Try to use models with similar concepts which help infer the intended assertion
  • Pre-conditions exist in the test setup
  • Post-conditions verify that the assertion holds true
    • Using these pre/post conditions help a develper understand what’s happening when a procedure is used
  • Combining Intention Revealing Interfaces, Side Effect Free Functions and Assertions make encapsulation and abstraction safe
    • Paint mixing example in the book – mixin(otherPaint) – should the otherPaint be reduced in volume?
    • Changing an argument is a risky side effect and a bad practice

Conceptual Contours

  • “Cookbook rules don’t work”
  • Don’t try to make everything in a domain fit the same level of granularity
    • Will often either create too much duplication of code, or obscure the overall picture by introducing too many details – one size doesn’t fit all
  • As new concepts are introduced into the model, you may have to refactor to better suit the new concept
    • This creates the CONCEPTUAL CONTOURS – happens when code is adapted to newly understood concepts
  • Finding the conceptual unit of functionality will lead to more flexible and understandable designs
  • Decompose elements into units (operations, interfaces, classes and aggregates) – using intuition
  • The model should be aligned with consistent aspects so it’s understandable and meaningful
    • Should line up with the ubiquitous language
    • All of this typically comes from constant refactoring and almost never happens on the original design
  • If a new concept is introduced and requires significant refactoring, it may mean that our understanding of the domain needs to be revisited
  • Accounting example – refactoring the code to the domain enabled future updates that sort of just fit into place
  • Having these conceptual contours come out stabilize the model and make unit tests easier to create and understand

Standalone Classes

  • Difficulty of understanding a design increases drastically as dependencies are added
    • Implicit dependencies / references add to mental complexity more than explicit references
    • Implicit concept was the Paint example where red green and blue indicated pigment colors
    • This was made explicit as the Paint class was broken down and a Pigment class was added
  • EVERY dependency is suspect until proven as essential to the concept behind the object
    • Often scrutinizing these dependencies can result in eliminating all of them
  • When you can, eliminate all OTHER concepts other than the ones crucial to the class
    • This makes the class something that can be self-contained and easier to understand
  • Goal is not to eliminate all dependencies, rather just eliminate the non-essential ones
  • Intricate computations / algorithms should try to be factored out into value objects if possible
  • Low coupling reduces conceptual overload
    • Standalone classes are the definition of low-coupling

Closure of Operations

“Where it fits, define an operation whose return type is the same as the type of its arguments.”

  • Following this rule allow for interfaces that don’t introduce other concepts
  • Very often used with Value Objects
    • Not typically used with Entity objects because those aren’t “replaceable” objects – usually they are mutated
  • Constantly look for ways to reduce interdependence and increase cohesion
  • Additionally, using / returning known standard types can almost be as good as a Closure of Operation because it doesn’t add to mental complexity

Declarative Design

  • Definition: “A form of programming in which a precise description of properties actually controls the software. An executable specification.”
  • Domain-specific languages can be declarative
    • How to be a Programmer by Robert L Read series, specifically episode 40, How to be an Advanced Programmer
  • Benefits are realized once you have combinable elements that communicate their meaning and have obvious or no effects
  • “The ability to build complex specifications out of simple elements increases the expressiveness of the code.”
  • Favorite quote: “Using a pattern doesn’t mean building features you don’t need.”

Angles of Attack

  • So…we know we want to clarify the intent of code, make the consequences transparent and decouple the model elements…
  • So…where do we start? With the easy stuff!
  1. Carve off Subdomains that are easy
  • Move the complex rules out, make them declarative
  • The new subdomains are clean, and the old is cleaner than it used to be
  • “It is more useful to make a big impact on one area, […] than to spread you efforts thin”
  1. Look for established formalisms…meaning…things that are easily understood

  • You don’t often get to create something completely new, most large loftware involves domains that centures old!

  • example: Accounting (well developed: notions like ledgers, payments, orders or even Math)

  • bonus: Math is often highly testable too! (Same w/ anything that is stateless)

  • It’s a contrived example, but still funny to see how clear it is to start and how much better it is at the end

    • Separated the query from the modifier (calculate + apply – Commands and Side Effect Free Functions)
    • Make implicit concepts explicit (Created an object for a group of objects) (lol – Share Pie – also Order/OrderItems)
    • Supple up the code! (Complex logic encapsulated, side effects minimized and suppled up, dependencies are minimized)

  • So…when it needs to change…Add a new loan type, money is probated based on the date

  • In the original “simple” code…it’s tempting to “if”

  • In the new code…make a ProrateStrategy…but why??? Because I can see how things work from the interface!

Domain Driven Design

Domain Driven Design

Resources We Like

Tip of the Week

Share the joy