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]