I’m currently on page 293. My goal is 50 pages which would mean that my goal is up to Chapter 14 (context map).

The last few days were pretty grindy and I try to finish the book as soon as possible. It would be perfect if I would finish today. But let’s see.

---

Refactoring

• Keep the model intact
• Keep the connection to the domain expert alive

---

Bounded context

Multiple models coexist on big projects, and this works fine in many cases. Different models apply in different contexts.

Explicitly:
* define the context within which a model applies
* set boundaries in terms of team organization
* Keep the model strictly consistent within these bounds

And use CI / Automated tests and build to keep the existing system working!

Context map

Code reuse between bounded contexts is a hazard to be avoided.

• Context map describes the point of contact between the models (language, sharing, etc.)

Furthermore, he presents several approaches to a common strategy. However, I found them so clear and obvious that I didn’t include them. The main idea is that either each domain is abstracted as much as possible, something in between or those two teams work together to create one common core.

---

The next chapter is about distillation which means reduce the models and making them simple to understand and more coherent.

Core Domain

• Important and central to the purpose of the system
• Most valuable
• Point of possible competitive advantage
• Small and of high quality

Techniques:

• Generic Subdomains Extract cohesive subdomains which are generic!
• Domain vision statement What is the core domain and how is it valuable?
• Highlighted Core Description of the core and interaction between primary core elements
• Cohesive Mechanisms Extract a cohesive mechanism into a separate framework (extract the what from the how)
• Segregated Core Strengthen the core by extracting supporting players and keep the core highly cohesive
• Abstract Core Abstract the core if it’s too complex and provide easier interfaces

---

The next two chapters are about Large-Scale Strategy which isn’t that relevant to me and my near future. Therefore I won’t go deeply into it but rather skim through it so that I know what possibilities there are.

---

Ok, done. I’ve just written a small review like every time. Great.

---

While reading DDD I had an idea of a DSL. However, I thought about it for a while and thought ‘Hey, this could be made easier by generating code’. All this led me to a topic I haven’t really learned about: XML.

Therefore, I decided to read a book on it, it’s called: XML: Visual QuickStart Guide by Kevin Howard Goldberg.

Interesting enough, one of the few books on XML which a good amount of positive reviews.

---

The layout of the book is awesome. On one side is the text and on the other the code the text is talking about. Absolutely great.

• XLS (eXtensible Stylesheet Language) made of
• XSLT for transformation
• XPath for identification
• XSL-FO for formatting
• DTD (Document Type Definition) defines structure
• XML Schema language also defines structure

---

A valid XML document consists of:

• a declaration
• a single root element
• child elements and attributes

Attributes should be used as meta data, i.e. data about the data!

You can use <!CDATA[ … ]]> to display elements as text.

---

Designing Beautiful Software

The craftsman is somebody who wants to build something that lasts.

That’s a good talk! Nothing new but a great summary of the most important best practices of OOP. That’s one of those talk which can serve as a starting point. Great for new developers!

---

Back to the book: XSLT. You start by entering a href to the xls file.

xml-stylesheet type="text/xsl" href="foo.xsl"?>

Those xls files contain templates (comparable to functions). The templates consists of

• a label which indicates where they apply
• the actual transformation

So, we declare a header again for the xslt file and inside it we can declare two things.

<xsl:template match="/">
    Some content we want to generate. And we can select
    attributes from our xml file:
    

Here the template matches the root.

XLS is basically a template language. There are other functions/tags like , or .

Interesting enough, there’s also the possibility of sorting the file:

<xsl:sort select="foo"
          order="descending"
          data-type="number" />

---

I won’t go into the detail of XSLT, etc. That’s something you can look up if needed. However, it’s interesting to learn about its ability.

---

DTDs aka. Document Type Definitions. It’s basically a schema of a xml file.

Here’s an example:

<!ELEMENT route (start, end, length, stop*)>

<!ELEMENT start (#PCDATA)>
<!ELEMENT end (#PCDATA)>
<!ELEMENT length (#PCDATA)>
<!ELEMENT stop (#PCDATA)>

PCDATA means parsed character data. In constrast to CDATA which means character data. You can also add qualifiers like * or ? or + to indicate how many of these elements should be included. You can do the same for attributes and declare choices.

---

There is also something called a XML Schema.

The same example like in DTD:

<element name="route">
    <complexType>
        <sequence>
            <element name="start" type="string"/>
            <element name="end" type="string"/>
            <element name="length" type="decimal"/>
            <element name="stop" type="" minOccurs="0" />
        </sequence>
    </complexType>
</element>

I think more readable and clearer in intent.

There are also namespaces which work like namespaces in other languages.

---

I just wanted an overview over the whole topic and I got it. It’s an interesting topic and I’m quite surprised how sophisticated the tools are. On the other side it feels bloated with several standards basically doing the same thing. It feels like it is designed by committee.

---

Software Architecture vs Code

There’s a discrepancy between architecture and code. Most architecture is layered architecture. The code however does normally look different.

An approach is architecturally-evident coding style, i.e. naming conventions, packing structure, etc. depended/similar to on the architectural model.

The C4 Model

• System context
• Containers (applications, etc.)
• Components (Services, modules, …)
• Classes (optionally)

Interesting, he suggests to move from a layers into a component. I personally did something similar in my most recent project. It’s nicer to understand. However, the testing becomes trickier.

Interesting talk. It was mainly about thinking for yourself especially towards some dogmas in the software industry.

---

So Long, and Thanks for All the Tests

Kent Beck:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.

Interesting that a lot of talks are about questioning dogmas. I like that. But I also think that anti-dogmas as dogmas are equally as bad.

What I never understood why some people focus solely on unit tests. They are good for some things but I want to see if my DB connection actually works or if I can upload something. Therefore, I write integration tests. If I find a bug I write a regression test, etc.

I have the feeling that either I don’t get something or I just use my common sense instead of swallowing some dogma.

---

My Take on PHP by Fabien Potencier

Interesting take. Especially the idea of PHP lacks as a language but shines as a platform. I agree with him that PHP got and gets better.

What I found interesting is the background of a lot of speakers in the PHP community. Most of them seem to come from a pragmatic background aka. I needed something to fix and did it. The atmosphere is very different to other languages. In my opinion, more down to earth and less arrogant as some other communities.

---

Another Zed Shaw talk titled The Imaginative Programmer

Good talk.

---

So, enough for today. I think I’m going to edit my project so far that I can publish it to github and then I’m going to test it in production. I don’t really need it anymore which is a bit dumb.

Nonetheless, I’m going to roll it out and implement an interface to test it live. When I’m done with that (which can take longer than just tomorrow) I want to start with symfony. I’m a complete noob in it and I want to build up my knowledge.

---

Updates Goals:

• Get a bit more exposure to OOP and OOD
• Learn Symfony2
• Learn a bit more about MySQL
• Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
• Watch one video per day on average

Progress status

Done

• Read Domain-Driven Design [done]
• Get a bit more exposure to OOP and OOD
• Read XML: Visual QuickStart Guide [done]

In Progress

• Watch one video per day on average [52 of 75]

Today, I will continue with DDD. My goal is 50 pages which is around the start of Chapter 7.

---

Modules (Packages)

Like everything else in a DDD, modules are a communication mechanism.

The same idea still prevails. Try to design to the domain. Modules should flow naturally.

Also keep modules and organization simple. A domain model should be represented as a domain model not a technical one.

---

Aggregates

A cluster of associated objects that we treat as a unit for the purpose of data change.

Consists of:

• Root a Specific entity, only object which can be referenced from the outside
• Boundary defines the content of the aggregate

Factories

Requirements:

1. Each creation method is atomic and enforces all invariants
2. Parameters of factory method should use the abstract type

Invariant checking makes the most sense in the case of value objects because they are immutable. In the case of entities the factory should use the entity’s methods to check invariants.

Repositories

A repository takes care of all queries and summary information about a collection. It’s like a SQL/DB layer however the technology behind it doesn’t matter.

if you find you need to search the database for a preexisting value object, it is worth considering the possibility that you’ve really got an entity whose identity you haven’t recognized.

---

Some terminology:

• Anti-Corruption Layer: \Translation layer between domain model and outside API
• Enterprise Segment: A way to break data down (time, attributes, etc.)

---

Listen to the language the domain experts use. Are there terms that succinctly state something
complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks
on their faces go away when you use a particular phrase? These are hints of a concept that might
benefit the model.

And read a book about the domain! It often contains explanations and models.

---

Specification

• states a constraint onto an other object; can test if object fulfils specifications

Purposes:

1. Validate object
2. Select object
3. Constrain creation

---

Supple design

How to strive balance between change and the domain mode

Intention-Revealing Interfaces

But if the interface doesn’t tell the client developer what he needs to know in order to use the object effectively, he will have to dig into the internals to understand the details anyway

Describe what classes and operations do, not how.

Side-Effect-Free Functions

An operation that mixes logic or calculations with state change should be refactored into two separate operations

Standalone Classes

Low coupling is fundamental to object design. When you can, go all the way. Eliminate  all other concepts from the picture. Then the class will be completely self-contained and can be studied and understood alone. Every such self-contained class significantly eases the burden of understanding a module.

Closure of Operations

Where it fits, define an operation whose return type is the same as the type of its argument(s).

---

I quite like his ideas about declarative specifications. The idea is that besides checking specifications you also include boolean operators. So you can write something like:

A.and(B) which returns a new specification which checks for A and B.

---

Updates Goals:

• Get a bit more exposure to OOP and OOD
• Learn a bit more about MySQL
• Learn Symfony2
• Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
• Watch one video per day on average

Progress status

In Progress

• Read Domain-Driven Design [293 of 560 pages]
• Watch one video per day on average [47 of 75]

I just published yesterday’s post and review. I’m thinking about watching some talks today. This is one of the things I want to push forward so I don’t have to care about it anymore.

---

PHP, Under the Hood

• SAPI = Server API (e.g. mod_php, fcgi, etc.)

Execution pipeline

• Startup
• SAPI <-> Request
• Shutdown

This happens once per lifetime of the engine.

For each request there’s:

• Request init
• Compile Code
• Execute Code
• Shutdown request

I wished that the talk would have gone into more depth and covered less. :/

---

Vertical reusability through components

He talks about building self-contained components which include everything from the model to the view. This reminds me a lot of Presentation-Abstraction-Control. He didn’t talk about that, yet. So let’s see.

• Data is rendered on the client side (templates can be created on the server)

Here’s how they describe it:

Looks very similar to PAC.

• Widgets pull the data they need which is defined in an abstract syntax

---

Making PHP go fast

 

• Interesting, no caching but fast page creation
• Data only generated when it changes

Pretty interesting talk.

---

How To Stop Sucking And Be Awesome Instead

• Software sucks but it gets better
• Boyd’s Law of Iteration:

Speed of iteration always beats quality of iteration

---

I decided to tackle Domain-Driven Design by Eric Evans. I read that the book is very wordy and a bit abstract. Nonetheless, I like the idea of DDD.

Let’s start:

Effective Modelling

1. Binding the model and the implementation (prototyping)
2. Cultivating a language based on the model
3. Develop a knowledge-rich model
4. Distilling the model
5. Brainstorming and experimenting

It’s about understanding the domain you’re modelling. The trick is that you use the existing business knowledge, the abstracts and translate them into your software.

It’s a neat idea because it makes talking about it and extending the system easier. If it there’s in the business it’s there in the software. Of course, you don’t want to model everything there is but nonetheless you know where to connect.

---

Vocabulary of the ubiquitous language

• Name of classes and prominent operations
• Terms about explicit rules
• Terms about high-level organization (context maps)
• Frequent patterns

---

• Talk out loud about your software to find a better abstraction. It should be crisp and domain-oriented.

The vital detail about the design is captured in the code.

n.c.

the Prolog language is a natural fit for model-driven design. In this case, the paradigm is logic, and the model is a set of logical rules and facts they operate on.

Interesting observation. Prolog is indeed excellent for this task because (theoretically) all you have to do is to define the model and Prolog takes care of the computation.

If the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software

Reminds me of one my favourite and probably most influential talks about software development I’ve heard. The speaker said (approximately): “I need experienced people, people how can write code and model effectively.” He needed and had Architect Developers.

  Every developer must be involved in some level of discussion about the model and have contact with domain experts.

---

When applying a framework, the team needs to focus on its goal: building an implementation that expresses a domain model and uses it to solve important problems

n.c.

• Entities Identity, can change state
• Value objects A state of something else
• Services Does something on request

Associations

Pretty interesting. He recommends making associations between classes as string as possible. This makes it easier to write code. These are the things he recommends:

1. Imposing a traversal direction
2. Adding qualifier
3. Eliminating non-essential associations

Entities (Reference Objects)

The identity doesn’t change though it state or attribute can. E.g. one gets older, looks different, may change their name, etc. Still the same identity.

Identity is a subtle and meaningful attribute of entities, which can’t be turned over to the automatic features of the language.

Later, he says quite well: A model must define what it means to be the same thing.

The basic principles of database design apply here as well.

Value Objects

• Are often parameters for messages between objects**
• Sometimes created and then discarded
• Used to create an Entity
• Immutable

Rule of Thumb: You care about only about the attributes!

Services

• Activities or actions, not things
• Relationship to other objects
• Purely defined in terms for what it can do for others

Characteristics of a good service:

1. Operation doesn’t naturally fit into entities or value objects
2. Interface is made up by other elements in the domain
3. Operation is stateless

---

Clean Code Talks: Don’t Look For Things!

• Ask only for that what you really want (constructors, etc.)

Isn’t it strange that a car knows how to build a factory and then uses the factory to build an engine for itself.

Love this. This works so nice with the recommended from DDD: Talk about your architecture out loud.

He mentions similar examples later on. I really like that! Definitely a technique I’m going to apply in the future.

• Ideally, we want nothing but assignments in the constructors

---

Enough for today! DDD is a slow read but very interesting.

---

Updates Goals:

• Get a bit more exposure to OOP and OOD
• Learn a bit more about MySQL
• Learn Symfony2
• Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
• Watch one video per day on average

Progress status

In Progress

• Read Domain-Driven Design [109 of 560 pages]
• Watch one video per day on average [47 of 75]