Episode 07 – Architecture

Clean Code

Episode 07

The seventh episode talks about how architecture encompass the highest level of abstract decision to the lower level of implementation.

  • What is architecture
    • Architecture is about usage
      • Architecture should expose the use case and not the delivery mechanism. Use case that should not be couple with the delivery mechanism.
      • Architecture should show the intent
    • Deferring decision
      • Good Architecture maximize the number of decision not make
      • Defer to make the decision by designing a structure that decouple from them and make the decision irrelevant.
      • Decouple tool, frame work and database by focuses the architecture on the use cases not on the software environments.
    • Separation of value
      • Make UI as a plug in to the use cases. By separating them, it is easy to understand the cost of UI and use cases individually. All system component should be isolated because of this.
  •  Use cases
    • What really is Architecture
      • The system of an accounting system should scream accounting and not web system, which is a delivery mechanism to the accounting.
      • How the user interact the system with the delivery mechanism. Use cases that does not use word to imply delivery mechanism.
      • Use cases should be the central structure of the system where the abstraction is build upon. This is the intent of the system.
    • What are Use cases
      • Its a formal description on how the user interact with the system. It talks about what data and command that goes into the system and how the system response to them.
      • Primary course is normal interaction between user and system while Exception course is where error handling uses.
  • Partitioning
    • Three fundamental objects
      • Business object – Entities
        • application independent business rules
        • the method on Entity objects performance is valid on any application that the entity can be use in.
        • Entity object should not have any application specific method. Any such method should be in the interactor object.
      • User Interface object – Boundaries
        • Boundaries object shoulder one of the job of use case is to accept data from user and output data back to user.
        • Boundaries object isolate the use cases from the delivery mechanism to the system use cases.
      • Use case object – Interactors
        • Use cases are application specific business rules and implement by interactor object.
      • User <–> Delivery Mechanism <–> [ ( Boundary <–> Interactor <–> Entity ) System Architecture ]
  • Isolation
    • The delivery mechanism should have source code dependency pointing toward the system.
    • Model View Controller.
    • Database
  • Case Study
    • The stalk holder meeting
    • Analysis
      • Make use cases agnostic by separate what is matter (how to response to commands and data) and what is not (delivery mechanism)
    • Interaction and Databases
    • The underlying abstraction
  • References
    • Object-Oriented Software Engineering, by Ivar Jacobson
    • Writing Effective Use Cases by Alistair Cockburn
    • User Stories Applied by Mike Cohns
    • Agile Software Development by Robert Martin
    • Agile Principles, Pattern and Practices in C# by Robert Martin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s