Bài Thơ Đôi Dép

Tags

(Nguyễn Trung Kiên)

Bài thơ đầu tiên anh viết tặng em
Là bài thơ anh kể về đôi dép
Khi nỗi nhớ ở trong lòng da diết
Những vật tầm thường cũng viết thành thơ

Hai chiếc dép kia gặp gỡ tự bao giờ
Có yêu đâu mà chẳng rời nửa bước
Cũng gánh vác những nẻo đường xuôi ngược
Lên thảm nhung, xuống cát bụi cùng nhau

Cùng bước cùng mòn không kẻ thấp người cao
Cùng chia sẻ sức người chà đạp
Dẫu vinh nhục không đi cùng người khác
Số phận chiếc này phụ thuộc chiếc kia

Nếu ngày nào một chiếc dép mất đi
Mọi thay thế sẽ trở thành khập khễnh
Giống nhau lắm nhưng người đi sẽ biết
Hai chiếc này chẳng phải một đôi đâu

Cũng như mình trong những phút vắng nhau
Bước hụt hẫng cứ nghiêng về một phía
Dẫu bên cạnh đã có người thay thế
Mà trong lòng nỗi nhớ cứ chênh vênh

Đôi dép vô tư khắn khít bước song hành
Chẳng thề nguyền mà không hề giả dối
Chẳng hứa hẹn mà không hề phản bội
Lối đi nào cũng có mặt có đôi

Không thiếu nhau trên những bước đường đời
Dẫu mỗi chiếc có một bên phải trái
Nhưng anh yêu em bởi những điều ngược lại
Gắn bó đời nhau bởi một bước đi chung

Hai mảnh đời thầm lặng bước song song
Sẽ dừng lại khi chỉ còn một chiếc
Chỉ còn một là không còn gì hết
Nếu không tìm được chiếc thứ hai kia

doi dep Bài thơ đôi dép

Cuộc đời ta mãi mãi chẳng xa lìa
Mất một chiếc, chiếc kia vào sọt rác
Hay cố lê bên những gì phế thải
Sống âm thầm nơi xó góc tối đen

Rồi ngày kia buồn chán không ánh đèn
Chiếc còn lại cũng ra đi vĩnh viễn
Ngày ra đi không một người đưa tiễn
Nhưng vui lòng vì gặp lại chiếc kia

Một nơi xa hai chiếc chẳng chia lìa
Vì đã thoát khỏi cảnh đời ô trọc
Không hơn thua ghét ghen hay lừa lọc
Bước song hành một dạ đến ngàn thu

Tình yêu không nán đợi ai

Tags

,

Có nhiều cuộc tình không hề bắt đầu bằng câu nói “Anh yêu em”/”Em yêu anh”, mà bắt đầu ngay lập tức bằng một nụ hôn, một cái nắm tay, thậm chí một cái ôm chầm sau nhiều xa cách.

1. Người con gái tỏ tình trước, thường là cô gái si tình đến ngây dại khờ khạo, thậm chí sẵn sàng đánh đổi lòng tự trọng bản thân để cầu xin tình yêu của một người con trai.

Người phụ nữ cầu hôn trước, lại thường là người phụ nữ tỉnh táo, cá tính, mạnh mẽ và yêu say đắm. Họ biết họ đang tìm kiếm điều gì, và tin rằng họ sẽ có được thứ hạnh phúc xứng đáng.

Dân gian hay gọi đó là cọc đi tìm trâu! Dân gian thật lạ, dân gian chỉ chấp nhận những người phụ nữ đưa đơn li dị trước, khi mọi sự đã rồi, hôn nhân đã không đạt được mục đích, tình yêu đã thất bại. Còn người phụ nữ chủ động tìm kiếm hạnh phúc và tình yêu, dân gian lại cứ chê trách họ là cọc tìm trâu, hão huyền phi lý và có vẻ trái chiều đạo đức truyền thống.

Dân gian chỉ chực chờ cô gái thất bại, để úp lên đầu cô ấy lỗi “cọc tìm trâu”!

Tôi cứ nghĩ mãi về hình ảnh so sánh ấy. Nếu người con trai là trâu, hẳn tới mùa yêu, người con trai sẽ đi tìm một cô trâu cái có đôi mắt ướt, chứ tại sao lại phải đi tìm cái cọc?

Nếu người con gái là cọc, hẳn bạn đời của cô ấy, trong hình ảnh so sánh trên, chính là sợi thừng gần gũi, chứ đâu phải chú trâu vô tâm, dù buộc cách gì cũng chỉ muốn đi ăn cỏ xa, xa nhất mức độ mà sợi dây ràng buộc còn cho phép!

Và đàn ông, cứ cho là trâu đi, đâu có ngốc tới mức, cái cọc nào chạy tới là buộc được? Và cọc cũng đâu có ngốc tới mức cứ khăng khăng làm ngược lẽ đời, nếu như trong tim cô ấy đã không tràn đầy tình yêu và hy vọng, đến mức phải mở lời?

2. Cách đây bốn năm năm, khi tôi còn là phóng viên thực hiện các chương trình phỏng vấn đường phố tại Đài Loan để phát trên sóng của Đài truyền hình Việt Nam, có một lần tôi đã thực hiện clip phỏng vấn đề tài này: Con gái hay con trai nên ngỏ lời trước?

Tất cả những bạn trẻ Đài Loan đều trả lời trước ống kính truyền hình: “Ai ngỏ lời trước chẳng được? Nếu đã yêu nhau, cả hai đều yêu nhau, thì ai ngỏ lời trước cũng sẽ thành đôi, thành lứa. Còn nếu chỉ một người yêu đơn phương một người, thì con trai hay con gái ngỏ lời trước, khả năng rất cao là đều thất bại!”. Tôi không biết những bạn trẻ Việt Nam sau khi xem chương trình của tôi thực hiện thì suy nghĩ gì.

Chúng ta đã sống ở kỷ nguyên mới, nơi tình yêu và cảm xúc thực sự trong tim quan trọng hơn rất nhiều so với những nghi lễ, ràng buộc, lề thói, sự ngại ngùng giới tính, lời thị phi của những kẻ vô công rồi nghề xung quanh ta. Nếu người phụ nữ thực sự muốn người con trai ngỏ lời trước, cô ấy sẽ có vô số tín hiệu và tạo ra vô số cơ hội để người con trai tỏ tình trước!

Điều ấy hoàn toàn không liên quan tới việc, vị trí của cô ấy là cái cọc, phải đứng yên một chỗ chờ tình yêu tới!

Và nếu người con trai vẫn không ngỏ lời, thì không phải là vì anh ta ghét cái vụ “cọc tìm trâu hay trâu tìm cọc”, chỉ là anh ta không đủ tình yêu mà thôi! Và anh ta chưa yêu hoặc chưa đủ yêu cô ấy mà thôi!

3. Dường như phụ nữ vẫn phải nhường một lối cho đàn ông chủ động bước vào đời mình, hoặc bước vào cuộc tình mình! Nhiều người cho rằng, như thế mới bền được cuộc tình, mới lâu dài được hạnh phúc. Có thật vậy không?

Thật hài hước, có nhiều cuộc tình không hề bắt đầu bằng câu nói “Anh yêu em” hoặc “Em yêu anh”. Mà bắt đầu ngay lập tức bằng một nụ hôn, một cái nắm tay, thậm chí một cái ôm chầm sau nhiều xa cách, một ánh mắt da diết nhìn nhau qua một đám đông, không thấy đám đông, chỉ thấy nhau!

Những điều ấy dường như ngay lập tức, được tới từ cả hai người, không thể phân biệt được ai nhìn ai trước, ai có ý nghĩ ôm ai trước. Có một đôi mình quen, học cùng nhau năm sáu năm thì không tỏ tình, nhưng chỉ một đêm lửa trại dựa vào vai nhau ngắm trời sao, sáng sau đã thành tình nhân! Tức là tình yêu bắt đầu từ trước đó rất lâu, sự tha thiết đã ở trong trái tim rất lâu, đâu phải cứ khi chàng trai phát tín hiệu, cô gái mới có thể đón nhận hoặc bày tỏ?

Tình yêu là một hành trình mới, mà nếu chỉ một người bước tới, chắc chẳng thể thành đôi. Thật sai lầm khi những cô gái nghĩ rằng, mình yêu anh ấy, nhưng mình sẽ ngồi sau cánh cửa này. Chỉ cần anh ấy đẩy cửa, mở cửa ra, mình sẽ là của anh ấy. Còn nếu không, mình sẽ ôm tình yêu mãi mãi chôn trong trái tim này.

Cơ hội hạnh phúc thường trôi qua vào lúc ta không ngờ nhất.

 

Theo MASK

Anh chỉ cho em cách hạnh phúc nhé!

Tags

,

Đưa – tay – đây, tôi kéo em về cùng hiện tại… Đưa – tay – đây, tôi chỉ em lối đến yêu thương…

Em!

Đã bao giờ, em tự hỏi trong những hạnh phúc em đang đi tìm, đâu mới là hạnh phúc em cần chưa? Em đã bao giờ, thử một lần suy nghĩ về những điều em đang cố gắng, cho thứ hạnh phúc em gọi là hạnh phúc mong chờ chưa? Đã bao giờ em nghĩ những gì mình làm là đúng hay sai, là sai lầm hay đúng đắn chưa?

Tôi biết, em đã từng đi qua những tháng ngày đau thương không đáng có, vì em đã yêu bằng một trái tim quá nhiều mộng tưởng. Em cứ như nàng công chúa, mãi sống trong thế giới cổ tích của mình mà không chịu bước ra cùng hiện thực.

Em đã mơ những giấc mơ đẹp quá, em đã tin những niềm tin lung linh quá, và em đã yêu một tình yêu mà em luôn hy vọng sẽ đẹp như những giấc mơ kia… Đấy chỉ là mộng tưởng thôi em…

Tôi biết em đã khóc cho những nỗi đau rỉ máu trong tim từng ngày, từng ngày qua. Những nỗi đau chẳng ai làm chủ, những nỗi đau chỉ của riêng em và cũng chỉ mình em hiểu. Em đã khóc như thể em đang trút đi nước mắt, em có biết tiếc không em những giọt yêu thương, em có biết tiếc những niềm vui bị chìm trong nước mắt? Em có tiếc không em những ngày em nhìn đời qua đôi mắt khóc?

Tôi hiểu, em luôn muốn tìm cho mình một chỗ dựa, một cái ôm, một bàn tay. Tôi cũng hiểu em cần một ai đó nhiều hơn những gì em thể hiện, em yếu đuối gấp ngàn lần cái vẻ ngoài mạnh mẽ của em…

Nhưng sao cứ phải gồng mình lên như thế hả em?

Em đang cố làm chỗ dựa cho bao nhiêu người, nhưng chính em lại không có nổi cho mình một điểm tựa, thì em sẽ ngã thôi em à…

Ngã vì gánh lên mình quá nhiều đau thương của đời…

Em đã bao bao giờ nhận ra mình mù quáng khi luôn tặng đi những yêu thương vẹn nguyên để rồi nhận về những mảnh vỡ nát tươm…

Em có biết em thật ngốc bởi sau mỗi lần đau, em lại yêu nhiều hơn và niềm tin cũng vì thế mà nhân lên…

Có thể em thích sống với những suy tư của mình, em muốn sống trong cuộc sống nội tâm của em mà chỉ mình em hiểu…

Em luôn muốn mọi người chia sẻ với em những vần đề của họ, em luôn muốn những người quanh em coi em là một ai đó họ cần khi tâm sự, nhưng những suy nghĩ của em, em chưa từng dám chia đi cho bất kỳ ai…

Em chỉ dám giữ nó cho riêng mình… Em biết thế là ích kỷ không em?

Sao em cứ cố chấp giữ những mảnh vỡ yêu thương kia cơ chứ, chẳng phải tim em đang rách ra vì những vết cứa kia ư? Sao em không dám cho đi để về cùng thanh thản? Sao em lại sợ chính yêu thương em mong đợi?

Em đã bao giờ nhận ra suốt những ngày qua em đi tìm một thứ chỉ nằm trong giấc mơ, trong khung tranh mộng tưởng chưa?

Em có nhận ra, cuộc đời em với những tháng ngày đã qua luôn là những cái ngoái đầu để nhớ và những cái nhìn với theo…

Em luôn vô tình ngoái đầu lại phía sau, để rồi gặp một ai đó, một cái nhìn mà em luôn mải miết đi tìm những ngày sau đó, những cái chỉ đến duy nhất một lần. Và cũng là em luôn thích đứng nhìn ai đó từ phía sau lặng lẽ

Em luôn ở đâu đó phía sau nhưng lại chẳng bao giờ đủ can đảm để có thể ở bên ai đó, một cách song song, để một ngày giữa dòng người bon chen, bóng hình đó vút xa khỏi tầm mắt em, và em lại tiếp tục đi tìm hình dáng em vô tình để lạc…

Em cứ mãi nhìn với theo khoảng không trống vắng trước mắt em, em cứ mãi tìm cho dù là không thấy…

Đã bao giờ thử một lần tập quên những cái nhìn: một lần rồi nhớ mãi kia chưa?

Đã bao giờ em thử tiến lên để đứng cạnh ai đó em yêu thương chưa?

Đừng mãi làm cái bóng đi sau ai đó mãi thế em, thử bước lên đứng trước hạnh phúc của mình một lần đi em!

Em sẽ thấy cuộc đời em không chỉ mãi là những cái nhìn ngoái lại và những lần với theo thế nữa.

Sao em lại yêu những cảm xúc của mình nhiều như thế?

Sao em lại yêu những giấc mơ kia đến thế?

Sao em cứ để những thứ chỉ thoáng qua kia in hằn mãi trong trí nhớ?

Đó chỉ là một cái nhìn, một cảm xúc đã qua, một giấc mơ chẳng thể thành hiện thực thôi em à!

Tạm cất chúng đi ngay cả khi chúng là những kỷ niệm rất nhiều và rất đẹp… Gói gọn chúng vào miền quá khứ đi em…

Đưa – tay – đây, tôi kéo em về cùng hiện tại…

Đưa – tay – đây, tôi chỉ em lối đến yêu thương…

 

Theo MASK

Lạy các công ty bán hàng đa cấp, tội chúng tôi lắm!

Tags

Backyhanoi

Xin chào các bạn, mình muốn viết một bài về bản thân và tâm trạng rối ren của mình. Thật sự rất đau khổ khi gặp dự án của một công ty bán hàng đa cấp. Mình biết dự án này cách đây 7 tháng. Ban đầu mình nghe một người bạn nói và khuyên mình nên làm vì nó thay đổi được số phận. Một tháng có thể thu nhập lên đến vài ngàn đô, và chỉ từ 3 đến 5 năm là kết thúc cuộc đời làm kinh tế. Thực ra mình không tin và không muốn nghe, vì xưa giờ đa cấp đã quá nổi tiếng là lừa đảo.

Những lúc mình nói vậy, bạn mình bảo: “Nếu nói đa cấp lừa đảo, vậy tớ đi”. Đó là câu hỏi rất thông minh của công ty khi đào tạo nhân viên của họ. Ai cũng vậy, vì họ biết chúng ta không thể nói theo cách của chúng ta để chứng minh được.

Và rồi hai tháng sau, người bạn đó quay lại, mặc đồ vest, mang giày bóng loáng và đưa những tấm hình đi Thái Lan về, chụp hình với những siêu xe. Bạn ấy nói hai tháng nữa bạn ấy được đi Tây Ban Nha, do công ty tài trợ. Thu nhập của bạn ấy hiện tại khoảng hơn 18triệu/tháng.

Mình quá kinh ngạc, cũng bắt đầu tin vì nhìn bạn ấy bây giờ rất bảnh, ăn nói lưu loát, bề ngoài thì rất bóng loáng. Mình bắt đầu tìm hiểu, lần đầu tiên ở một buổi hội thảo tại khách sạn, lúc đó bạn ấy cảm thấy chưa đủ thuyết phục với mình. Bạn ấy nói mình thu xếp đi Sài Gòn thì tham dự buổi lớn hơn, quy mô hơn. Mình cũng đi, vì mình nghĩ nếu là cơ hội, mình không muốn bỏ lỡ nó và mình tiếp tục thấy rung động.

Khi vào hội trường, mình được nghe nào là bác sĩ lên chia sẻ (mà sau này nghe kỹ mới nghĩ họ chỉ nói bác sĩ chứ khống nói ở bệnh viện nào). Rồi đủ thứ hết, mọi người ngồi dưới nghe nói Yes cũng Yes thêm ầm ầm. Mà lúc đó chắc họ cũng chưa thực sự hiểu gì. Nhưng mình cảm giác lúc đó mình bị thôi miên theo những gì họ nói, lòng mình rạo rực muốn thăm gia ngay và không còn nghi ngờ gì nữa. 

Trên đường về là buổi nói chuyện, chia sẻ về những gì nhận được. Mình thấy mọi người đa số là đi lần đầu tiên. Họ khóc có, cười có. Họ như một tín đồ của công ty và coi những người dẫn họ đi như là cha mẹ, ông nội… gì gì đó. Họ thấy biết ơn. Về đến nhà, hai hôm sau mình tiếp tục được bạn mình gọi ra quán cafe nói chuyện. Với tâm trạng rất hưng phấn, bạn ấy nói hùng hồn là chắc chắn mình sẽ làm được. 

dacap2-5206-1391762541.jpg
Ảnh minh họa: InImages.

Bạn nói: “Có muốn thành công không? Đi để tận mắt chứng kiến và về làm sẽ nhanh thành công hơn”. Mình nghe cũng có lý và đăng ký đi ngay. Mình nhớ lúc ấy mình chẳng biết gì, chỉ nghe bạn ấy nói là đặt cọc tiền vé máy bay và tiền vé tham dự hội thảo ở Thái Lan tổng cộng là 5,5 triệu. Còn phải chuẩn bị thêm tiền để qua đó lo chi phí ăn ở. Mình quyết định làm liều, đi vay mượn được 8 triệu và đặt cọc ngay. Nửa tháng sau, mình đi Thái.

Qua đó, còn ngạc nhiên hơn nữa với những người lần đầu đi nước ngoài như mình. Hội trường phải đến gần 5.000 người đến từ đủ thứ nước, vì mình thấy rất nhiều là cờ của nhiều nước. Ở phía trước là 2 dãy siêu xe. Ngoài ra những âm thanh hô vang khẩu hiệu công ty được mọi người Việt Nam hét ầm ầm. Mình nghĩ, nếu là lừa đảo, không lẽ tất cả mọi người ở đây đều bị lừa, và tất cả họ đều ngu như tôi? Vậy là tôi tin… và từ đây, bắt đầu những tháng ngày đau khổ của tôi, tôi xin kể để mọi người có thể hiểu.

Về Việt Nam hai ngày, tôi nhận được điện thoại của bạn tôi hẹn ra quán cafe. Bạn tôi hỏi: “Sao rồi? Tin chưa?”. Tôi trả lời rất chắc chắn là tôi rất tin, và mong muốn được làm sớm. Lúc này bạn tôi mới nói, bây giờ bắt đầu, thì có 3 gói để bạn lựa chọn, thứ nhất là gọi 100pv (tương đương 4 triệu). Thứ 2 là gói 200pv ( tương đương 8 triệu) và gói VIP 500pv (20 triệu). Và hỏi tôi muốn tham gia gói nào?

Khi tôi hỏi kỹ từng gói, bạn tôi nói, gọi 100pv, và 200 pv chỉ là khách hàng thông minh sử dụng sản phẩm thôi, chứ không kiếm được tiền, tức là không có lương. Chỉ có gói 500pv thì tôi mới cơ hội nhận được lương mỗi tháng vài ngàn đô. Bạn ấy nói tôi hãy chọn đi, trong này không bắt ép ai hết.

Nói là không bắt ép, nhưng tôi vẫn bị phải vào gói 500pv. Tôi tìm đến công ty đa cấp là để làm, chứ đâu phải mua hàng sử dụng?

Trong đầu tôi bắt đầu có một sự nghi ngờ, và dường như bạn tôi nhận ra điều đó, nên nói qua chuyện khác, nào là trong này có anh chỉ chở chuối, khổ lắm. Mà bây giờ thu nhập gần 100 triệu. Không lẽ bỏ ra 20 triệu thôi để thay đổi tương lại cũng không muốn sao?

Rồi nói tới tư duy kém hơn ông xe ôm, xe ôm muốn chạy xe họ phải đầu tư mười mấy triệu để mua xe chạy. Và hàng tháng thu lại được có vài triệu, trong khi mình bỏ ra chừng đó, thu lại gấp bội lần, tại sao không? 

Tôi nghe cũng có lý, dường như tôi bị cuốn theo những gì người ấy nói, và không còn là tôi nữa. Nhưng về đến nhà, tôi lại suy nghĩ, sao ban đầu bạn tôi nói để làm dự án này, không cần vốn? Không cần kinh nghiệm, và không có rủi ro? Nếu tôi bỏ ra 20 triệu mà không làm được sẽ thế nào? Tôi gọi điện thoại ngay cho bạn ấy để hỏi, bạn ấy cười to và nói với tôi: “Đó không phải là đầu tư!”. Đó là mình bỏ ra để mua sản phẩm về sử dụng cho riêng mình, có buôn bán gì đâu mà đầu tư? Vả lại ai cũng làm được, tại sao nói bản thân mình không làm được, tự tin lên?

dacap1-1916-1391762541.jpg

Trong lúc đó, ai cũng bảo tôi coi chừng bị lừa, ba mẹ tôi thì la mắng và nói sẽ bị lừa cho mà xem. Nhưng tôi mặc kệ và đưa ra vài lý luận mà tôi học được ở công ty. Rồi tôi bắt đầu công việc nhanh chóng. Tôi hẹn những người mà tôi quen biết ra cafe để nói chuyện, và dĩ nhiên gần hai tuần uống nước đó, tôi phải tự trả, số tiến chi đã lên đến tiền triệu mà vẫn không ai đồng ý làm. Vì họ nói lừa đảo, tôi buồn lắm.

Lại liên hệ với người upline (người có cấp cao hơn trong công ty bán hàng đa cấp) của mình – bạn tôi nói: “Từ từ, cái gì cũng không vội vã được. Tôi chỉ cần tìm 5 người tham gia, vậy là giàu rồi. Nên 100 người tới hẹn, chắc chắn sẽ có 5 người đồng ý”. Tôi nghe lại thấy bùi tai. Những tháng ngày đó tôi rất khổ sở, vì tiền chi phí đã không còn. Nhưng bạn tôi lại nói, phải cố gắng vay mượn một ít, rồi từ từ mình trả, mình sắp giàu rồi.

Bạn tôi nói đầu tư vào ăn mặc, điện thoại, tóc tai để thật ra dáng. Vì mình làm dự án 4.000 USD cơ mà, phải thể hiện cho người ta tin, không lùi xùi được. Tôi nghe thấy có lý. Vậy là về nhà, tôi lại vay mẹ một ít tiền đi mua sắm ít quần áo. Đổi một chiếc điền thoại nhìn cho ra dáng.

Tôi cứ quyết tâm làm. Ngày nào cũng hẹn, cũng gặp. Nhưng chỉ vài người tham gia đi off xong, về họ lại từ bỏ. Tôi bắt đầu thấy lo lắng. Vì số tiền tôi vay để đi Thái, để vào gói 500pv, để cafe hẹn gặp,… đã lên đến con số gần 30 triệu. Tôi biết làm gì để trả nợ đây?

Đang lo lắng thì bạn tôi lại hẹn gặp, nói bây giờ đã qua tháng mới, tháng này chắc chắn sẽ tuyển được người, và có thu nhập. Nhưng nếu muốn có thu nhập, phải tham gia vào gói duy trì 200pv mỗi tháng, tương đương 8 triệu nữa. Trời ơi, sao bây giờ bạn mới nói cho tôi biết? Tiền đâu ra để tôi tiếp tục đây?

Bạn tôi nói, ráng đi, đây là quy định rồi. Chỉ một thời gian ngắn nữa, chỉ cần ba người tham gia, là tôi sẽ có thu nhập rồi. Và bạn tôi khoe lương tháng này của nó là được 24 triệu.

Tôi nghĩ bây giờ phóng lao phải theo lao thôi. Ban đêm nằm nghĩ có lẽ tôi đã bị lừa, ban đầu nói là không cần vốn. Sau đó đùng một phát phát thông báo nộp 20 triệu. Nói là chỉ tham gia một lần trong đời làm kinh doanh thôi, bây giờ lại mọc ra 8 triệu nữa. Tôi biết kiếm ở đâu? Tôi trằn trọc, nhưng tự dối lòng là không đâu, không bị lừa đâu. Vì mọi người người ta làm được vậy cơ mà.

Mỗi lần đi hội thảo là mỗi lần về hưng phấn. Sau này tôi mới nghĩ opp hay nói chuyện với upline như là bị thôi miên, là phải làm theo ý họ… Có lẽ là vậy. Bắt buộc phải đi nếu muốn nhanh thành công và có tiền trả nợ.

Một lần nữa tôi bị cuốn theo chiều gió, tôi về tiếp tục vay mượn, thêm 8 triệu nữa để thu xếp đi Thái lan lớp đào tạo. Mà bạn tôi nói là không phải ai cũng đi được, phải xét, và bạn tôi xin mãi mới được 1 xuất cho tôi đi. Giá vé tham gia là 7 triệu , cộng với tiền máy bay nữa là 10 triệu.

Lạy trời, tôi quyết định chai mặt đi vay tiền. Lúc đó gặp các bạn trong nhóm upline, ai cũng nói hồi đó họ cũng khó khăn y như vậy. Có người phải cầm xe, bán hết những gì họ có để tham gia, và bây giờ họ đã có tất cả. Tôi lại tin và tiếp tục mắc sai lầm.

Đi Thái Lan về được nửa tháng, tôi lại bị upline hối thúc hoàn thành gói duy trì 200pv, phải thật nhanh trước ngày 12 của tháng thì mới được học lớp làm thủ lĩnh… Đối với tôi, thời gian khi tôi tham gia vào công ty bán hàng đa cấp quay vòng đến chóng mặt. Lúc này đã có hai bạn tham gia vào gói 500pv của tôi. Tôi mừng lắm, nhưng lại xoay tiền để duy trì, cafe, và những khoản khác. Tôi lại phải cầm cố chiếc xe của mình lấy 10 triệu.

Lúc này tôi nghĩ tôi đã đánh đổi cả cuộc đời tôi, vì nếu thất bại, gia đình, bạn bè sẽ cười tôi. Và tôi không còn tiền để trả nợ. Vậy là số tiền tôi đầu tư vào công ty bán hàng đa cấp đã lên gần 60 triệu. Tôi không nghĩ nó nhiều đến vậy, tôi chưa bao giờ nghĩ mình sẽ làm ra con số ấy.

Rồi một ngày, tôi đến một quán cafe để hẹn một người mới. Trong lúc ngồi chờ đợi, tôi nghe sau lưng một câu chuyện, một câu chuyện làm tôi khóc. Tôi bừng tỉnh, nhưng đã quá trễ.

Một người phụ nữ trông rất sành điệu (theo kiểu cao bồi thôn), tay sục sục một chai nước màu xanh, mà tôi biết đó là diệp lục, là người cùng công ty đa cấp. Chị ta gọi điện thoại cho một người:

“Chị có muốn thành công không? Có muốn có tiền trả nợ không? Có muốn con chị được đi học Đại học không? Nếu có thì hãy nhanh lên. Thu xếp đưa em 20 triệu để em lấy hàng. Và đăng ký thành viên VIP cho chị. Và chị tuyển được 5 người, là lúc đó thu nhập của chị không dưới 20 triệu đâu.

Tin em đi, không lẽ em mà lại đi lừa chị sao? Không tin em sao? Mình cùng nhau làm cho cuộc sống trở nên tốt đẹp hơn mà chị”.

Bên máy bên kia ầm ừ gì đó, rồi chị này tắt mày cười ha hả lên, nói với chị ngồi bên cạnh: “Em lừa được bà Phương rồi chị à, thế là thêm một con nhạn đã bị lừa. Thôi thì thông cảm nhé, vì cuộc sống cả thôi, chị ráng mà đi lừa lại người khác để kiếm cơm”. 

Nói xong chị ta lại cười ha hả. Lòng mình bắt đầu nóng rực lên, nước mắt ừng ực chảy ra. Nhắn tin cho bé khách hàng nói hủy cuộc hẹn, để ngồi nghe tiếp câu chuyện. Nghe chị ta kể về thành tích mới 6 ngày lên được chức director. Mình nghe quen quen, quay lại nhìn… Thì ra đó là chị T.T.C, người hôm hội thảo đã lên chia sẻ thành công. Nói trong nghẹn ngào, và làm mình khóc một trận: “Không ngờ bây giờ lại trở thành cáo đến vậy”.

Nghe ngóng tiếp câu chuyện, mình nghe chị này bảo chuẩn bị đi Thái Lan tham gia hội thảo,  nhưng em không tốn đồng nào đâu nhé. Thế chị kia mới hỏi sao đi nước ngoài lại không tốn? Chị T.T.C mới kể:  “Chị biết không, vé tham dự chỉ tầm 1,7 triệu – 1,8 triệu thôi. Nhưng em cứ hô lên là 2,5 triệu thế là chúng nó nộp cho em. Chúng nó đâu gì về tiền đâu, chỉ có upline như em là biết đích thực là bao nhiêu thôi.

Vì qua đây, chỉ phát cho cái thẻ để ra vào, chứ có ghi tiền bạc gì đâu. Thế là chúng em qua đó chỉ cần dắt theo tầm chục người là có tiền ăn xài thả ga, mà ăn sang nhé! Tiền của chúng nó cả, vậy mà đứa nào cũng tấm tắc: “Upline sài sang thế này chắc lương cao lắm. Em chỉ cười, mà trong bụng cười đến tung cả ruột. lũ ngu!”

Trời đất, nghe đến đây, tim tôi như đập muốn tung lồng ngực. Ngày đó tôi cũng nộp tiền đi Thái là 2,5 triệu – là tiền tôi đi vay, đi mượn. Vậy mà người ta nỡ làm vậy. Tôi bắt đầu ôm mặt khóc. Khóc vì mình ngu, mình đã bị lừa. Ráng chịu đựng, tôi ngồi nghe tiếp xem chị này nói gì nữa. Chị tiếp tục: “Người này lừa người kia, người đi trước lừa người đi sau. Khi họ đã tham gia là không dứt ra được, vì phải cố mà đi lừa để có tiền mà trả nợ. Ai vào đây cũng nợ nần thôi, lấy tiền đâu ra?”

Tôi nước mắt ngắn, nước mắt dài ra về. Trời lại mưa, tôi mặc kệ. Tôi vừa đi vừa khóc, nhận ra một giá trị ở công ty đa cấp là “lừa đảo mới tồn tại được”.

Còn nhớ một câu mà người nói: “Họ cười tôi, vì tôi không giống họ. Tôi cười họ, vì họ quá giống nhau”. Đúng, tôi đã bị cười là những người như tôi quá ngu, để họ ăn tiền của chúng tôi và còn cười vào mặt chúng tôi. Vì chúng tôi quá ngu giống nhau.

Về đến nhà, một đêm tôi không ngủ được. Tôi suy nghĩ có nên dừng lại hay tiếp tục? Dừng lại, tiền đâu tôi sẽ trả nợ? Tiếp tục, thì tôi lại phải đi lừa người khác? Để họ sẽ khốn đốn như tôi bây giờ?Sau một đêm, tôi quyết định dừng lại. Tôi không thể nhẫn tâm đi lừa những người người tội nghiệp kia được. Họ đều là những người có hoàn cảnh khó khăn. Nếu họ không lừa ai được, thì tiền đâu mà họ trả nợ?

Và liệu tôi lừa được họ vào hệ thống, tôi có ăn ngon, ngủ yên với đồng tiền khốn khó của họ không?Dừng lại thôi! tôi bắt đầu không tham gia, không liên lạc với ai nữa. Rồi xin một công việc đi làm, hẹn những người cho tôi vay là tôi sẽ cố gắng làm và trả nợ cho họ. Tôi thú nhận “tôi đã bị lừa”. 

Hên là mọi người đều là người thân, họ thông cảm và cho tôi khất nợ. Bây giờ gần Tết rồi, tiền bạc tôi không còn một đồng, xe cộ thì cầm cố, hàng tháng phải đóng tiền lời. Tôi đau khổ lắm.

Tôi mong những người chuẩn bị bước vào công ty đa cấp hay đã bước lỡ rồi, thì hãy suy nghĩ thật kỹ. Người đầu tiên mà công ty hướng dẫn bạn đầu tiên nên tuyển dụng là những người thân quen nhất… Đừng làm vậy với người thân, bạn bè của mình, tàn nhẫn lắm. 

Công ty bán hàng đa cấp, làm cho cuộc sống trở nên tốt đẹp hơn hay làm cho cuộc sống đau khổ hơn? Tôi mong các bạn nhận được qua bài viết này, và tìm hiểu thật kỹ trên báo chí. Báo chí, tivi đã đưa hết lên rồi, đừng sai lầm mà bước vào vòng luẩn quẩn này nữa.

Có thể một số bạn làm trong hệ thống công ty bán hàng đa cấp khi đọc bài này sẽ chửi tôi là thất bại nên nói lung tung? Các bạn sẽ hỏi tôi đã sử dụng sản phẩm chưa? Có tin sản phẩm không? Tôi xin trả lời luôn: Tôi đã sử dụng tất cả.

- Đối với bột diệp lục, tôi uống gần 4 tháng rồi. Vẫn không thấy gì thay đổi như quảng cáo. Tới tháng tôi vẫn đau bụng kinh bình thường, mụn vẫn mọc đều đều.

- Duy nhất có trà thải độc ruột là như quảng cáo là thải độc tố ra hết. Tôi ngoài cảm thấy uống vào là đi toilet cả ngày, không biết là có thải độc gì không? Chắc là có, vì chỉ thấy ở toilet liên tục.

- Tôi rất ốm, uống đã hết 3 hộp bổ sung đạm nhưng vẫn không thấy béo lên 1 kg nào.

- Chị gái tôi rất mập, cho uống hết 3 hộp giảm cân hết 6,6 triệu, 3 hộp nhuận tràng mà giảm được có 1,5kg. So với quảng cáo là giảm 5,7cm vùng bụng…

- Đạm đậu nành cũng vậy, uống thì dở mà rất đắt. Một hộp đậu nành gần cả triệu bạc. Uống được nửa tháng là hết rồi, thử hỏi nửa tháng uống đậu nành mà hết gần 1 triệu, vậy người ta uống đậu nành nguyên chất còn to hơn. Tất cả chỉ là giả dối, nói quá sự thật.

Tôi lạy các công ty bán hàng đa cấp, tội chúng tôi lắm! Đừng làm cho cuộc sống của chúng tôi khổ hơn nữa.

From http://ngoisao.net/tin-tuc/goc-doc-gia/choi-blog/lay-cac-cong-ty-ban-hang-da-cap-toi-chung-toi-lam-2948411.html

Multilayered Architecture (5) – The Presentation Layer

Tags

,

by 

Introduction

The final piece of a MultiLayered Architecture, in term of development design and dependencies is the Presentation Layer. It has mainly the scope to create an Interface with the final User of the application. It can take the form of Desktop forms, Java Applet, Web application and any other possible solution provided by technologies.

Interchangeability

At this stage, if all the other layers have been correctly designed, it will be very simple to create a Presentation Layer. Consider the case where the logic has to be distributed as a standalone application. In this case it will be great to integrate the created logic into a Rich Client Platform. Several good ones exist and I would like to remember the NetBeans Platform (actually my preferred one) and the Eclipse Platform.

But in another case it could be nice to deploy the application on the web, and so in that case all existing layers could be integrated with any web technology as JavaFX, GWT, JSF…

And in another case, why not use the same logic to be deployed both as desktop and web application? You just need to have a build of Domain-Application-Infrastructure layers to be bundled into two different Presentation implementation, and if overall design is enough good you will not need to duplicate any line of code.

Presentation Layer as an independent project

Clearly the Presentation Layer could be managed as an independent project. There are no constraints related to the moment where it has to start, the only constraint is that it must never influence the design and development of all the other layers.

There are several efforts related to this:

  • Avoid Logic to UI coupling in all code residing in other layers. Actually this type of coupling is considered negative and dangerous as it affects directly the Testability of the designed software solution (as discussed in another post here)
  • Analyst responsible of UI design can be different from business analyst, and in my opinion it is preferable. To design UI the most important thing is to have graphic design knowledge, even if the business knowledge is not full. Ugly UI are typically caused by the bad choice to let developers design them (not agree…?)
  • Force developers to test code writing automated tests and not simulating user interactions. This actually is a very bad practice, to test logic we create the UI, we simulate the user interaction, and finally we agree that code is safe and tested. But what about automation? And what about code and requirements coverage?
  • Think at the logic implementation and not how nice it is presented. If developers working on business logic do not have access to any implemented UI they will be obliged to think simply at the code they are writing and not at the way it is presented. And probably this lack of presentation will be positively replaced by an increasing amount of design documentation that has to be provided to document and explain the code.
  • Different Technologies need different profiles, so probably will not be the same team that is responsible of different implementations

Conclusion

The Presentation Layer is very important for the user, as you cannot do any demo without it, but in this post I wanted to put the focus on the fact that it must not be so important also for the developers. One of the most common errors when developing a software solution is to start thinking how it will look like, once instead this should not worry too much analysts, architects and developers since a separate team could be in charge of developing it. If all other layers provide well defined boundaries and interfaces, then the Presentation Layer could even be implemented before that concrete implementation of those interfaces exist, using stubs, mocks or fake objects.

Reference: Redundancy in Domain and Database Design from Marco Di Stefano at the Refactoring Ideas blog.

Multilayered Architecture (4) – The Infrastructure Layer

Tags

,

by 

Introduction

What is Infrastructure? If we think at a building, Infrastructure is what brings light and water. You can build a wonderful house, but if you don’t connect it to the city infrastructures, you will never be able to live in it. Finally this building is able to receive water and light, but is not linked to any specific water or light distributor. I can start a contract with energy company A and change to energy company B if needed.

If we come back to software engineering, Software Infrastructure is what gives energy to our system: a database technology, a network protocol, or a file system implementation. It is part of software architecture, but as for a building the vendor-neutral principle should be adopted, that means decouple the software architecture from any specific infrastructure implementation, to be able to switch easily from a technology to another.

Persistence layer

One of the most important part of the Infrastructure Layer is the Persistence LayerPersistent is whatever an object that is able to live independently of a software. Typically a database is a persistence representation of a certain set of data. As discussed in Domain Layer domain objects usually need to be persisted. But persistence is not directly part of business documents! You never speak about database table with business expert, but you speak about objects. So it is very important to keep the two concerns separated:

  1. The definition of business objects is part of the domain layer
  2. The mapping of business objects into a persistence model is part of the Persistence Layer (infrastructure layer)

A possible implementation

In my experience I learnt a way of implementing a Persistence Layer. As basic idea business objects are exposed only via interface. Pure implementation of those business objects are not exposed, and available simply usingFactories, also exposed via interface and gathered via Lookup or ServiceLoader. Finally to define the persistence layer with an ORM as Hibernate or EclipseLinkXML mapping is the preferred choice.

I know most of you will complain about the use of XML instead of Annotations, but annotations are too much intrusive for the scope that has been prefixed to separate business objects from their persistence infrastructure technology. Annotations put persistence metadata into the domain object, but what if those objects need to be reused by another application that want to persist them in a complete different way? The principle of separating the two concerns foster Reusability of the domain layer.

Multiple infrastructures

Hibernate could be just one of the possible persistent representation we want to give to our business objects; what if also we also want to be able to marshall them into XML? For this reason we could think to implementseveral infrastructure implementations, and make all of them available to be chosen dynamically at run-time, or statically at integration-time. The scope is that whatever implementation we use, the system has to continue to work in the exact way. It simply receives a source of data, if this source is an XML repository, a database or a file system, by the point of view of the application, nothing must change.

So a perfect implementation of a Multilayerd Architecture is one where a changement on the infrastructure will not have any impact on the other layers.

Multiple infrastructures

Conclusions

The Infrastructure Layer is what gives energy to a system, that means you will not be able to run a software without it. So even if designed as the last phase, it is implemented quite soon. It is also possible to implement some fake infrastructure technologies and postpone the final implementation, when domain layer will be fully implemented; this will avoid the risk to continuously change the infrastructure implementation every time business objects need to change.

Reference: Redundancy in Domain and Database Design from Marco Di Stefano at the Refactoring Ideas blog.

Multilayered Architecture (3) – The Application Layer

Tags

,

by 

Introduction

As Business Documents are considered the input for the Domain LayerSystem Requirement Specifications are the main input document for the Application Layer. Scope of this layer is to provide an implementation of the defined requirements for the system. So it is easy to understand that most of the logic contained is process oriented and so linked to a specific system implementation.

What is a Business Process?

In a general view, a Business Process (or simply Process) can be considered as a composition of several tasks, that composed together following a certain flow responds to the goal of automate a specific functional requirement. A process is generally mapped to a specific requirement, so it does not have a good chance to bereused by other process (except when a parent process composes several smaller processes), but a single task instead will probably have. What are the different types of tasks a process can compose? We could think to identify 3 main types: Business Tasks, Utility Tasks and Application Task.

Business Tasks

As discussed in a previous post The Domain Layer, a Business Task is considered to be agnostic logic that is part of the business model of the designed domain. To give a clear example, all logic related to a Factory or a Repositoryor a Validation Rule is considered as Business Task. To deeper analyze, what we will have inside a Factory is logic that permits to create a Business Entity in a state that is immediately considered as business validated. This code will surely be used in several processes, where for example several entities must be created at once.

Utility Tasks

Utility task is the best example of agnostic logic, cause it is naturally not related to any specific process or entity, as it simply provide valuable and reusable logic. An example of a utility tasks can be a task that given two points return their distance, or given a text return a formatted text following a certain format condition. Where this code is located depends on its purpose: if it is related to certain domain entities it could be in the domain layer, or if not related to any domain entity could be in the application layer. Sometimes, when working in an enterprise-wide environment, could be also interesting to have another layer with only utility tasks, to permit to be reused and shared between different applications. In an SOA for example it is normal to have a category of services labeled as Utility Services residing in a separate layer.

Application Tasks

An Application Task accomplishes the implementation of logic that is in the System Requirements but is not part of the Business Model of the Domain. I usually try to apply this definition, even if it is not always clear specially when business and system documents are not well separated (and this is the most common case…). Another way to describe an Application Task is as logic that extends features provided by Business and Utility Taks.

 The Process Logic

Finally Process Logic is considered all that logic that simply composes several tasks in a pre-designed logic flow, handling Exceptions and managing Transactions. So a Process normally does not implement any pure logic, but simply composes existing logic into a new configuration; that is why we could also classify it as a Controller. Processes are considered the entry point for each interaction with the system. WS-BPEL for SOA is an example of Language for process definition. For a desktop application, Processes are what UI Actions will directly call.

Application Services

As the Application Layer should stay agnostic about the Infrastructure implementation, sometime is necessary to delegate the Infrastruture Layer to implement application logic defined in the Application Layer. This is simply done as for the Domain Layer by defining simply the interface of the logic and then use the concept of interface-implementation separation, as discussed in Multilayered Architecture, to recall the actual available implementation of the logic. The following figure shows a final picture of what an Application Layer could contain.

Conclusions

The Application Layer contains logic that in most of the cases is specific to a system implementation. Anyway, to foster Reusability, it could always be separated in small horizontal layers that could be reused and integrated in different applications. User Interface and Infrastructure related technologies should still be kept away from this layer.

 

Reference: Redundancy in Domain and Database Design from Marco Di Stefano at the Refactoring Ideas blog.

Multilayered Architecture (2) – The Domain Layer

Tags

,

by 

Introduction

The domain layer is a collection of entity objects and related business logic that is designed to represent theenterprise business model. The major scope of this layer is to create a standardized and federated set of objects, that could be potentially reused within different projects. Once identified the enterprise business model segment that is useful for the project, it is necessary to start an analysis-model-design 3 phases process.

To achieve a good domain layer designs it is preferable that the following roles get involved during analysis:

  • business domain experts that bring their business knowledge

  • business analysts that study the domain and provide a first modelization

  • business architects that helps to prevent possible design problems that could arise during the design phase

Main design principles

I would like to put the focus on three design principles:

  • Use of design standards

  • Design agnostic entities

  • Keep away technology’s details

Use of design standards

Design standards are what make a project looks like a unique entity to IT people that are involved in its development and maintenance. Not using design standards is like starting to write a book in English, then continuing in Italian to finish in Chinese; for most of the readers it will be unreadable. As the domain is the first layer that is designed, design standards should be defined at this stage and a figure must be delegated to be the custodian. Finally design standards applied over the enterprise boost the interoperability, reducing the need ofintegration efforts.

Design agnostic entities

Domain entities are not coupled to any process definition. So they are intrinsically agnostic and potentiallyreusable. Potentially meaning that a certain effort has still to be done to give them a chance to be really reused. When we told that the scope of domain layer is to create a federated set of domain objects modelled from the enterprise business model, is not realistic to think at a whole enterprise modeling. In most of the cases a project will need to use just a small segment of it and so modeling will focus only on that part; this is what makes more complex to achieve reusability. In this scenario is easy to focus only on those aspects of the business objects that interest the specific project, mining the chance for those objects to be reused. A speculative or a deeper analysiscan help to better understand how those objects are viewed and used by other processes. Finally, before to model a new part of the business model, it is good practice to investigate if it can be already provided by other projects (well, if it is well designed for sure!).

Keep away technology’s detail

Technology is part of IT and never will be part of the business model! But still it is a common error to put technology concepts into the domain layer.

For example, a database is just a persistent representational model of domain entities, a domain entity does not exist because it is the ORM of a database table! Libraries like JPA or Hibernate should be excluded from the domain layer. If you understand that the domain layer represents the business model, you will accept that ORM is a top layer built on it for the scope of a project. Other type of technologies that are often bind to the domain are UI technologies, data persistence in general, and vendor platforms.

Domain layer classification

Inside the domain layer objects can be classified looking at their design time characteristics:

  • Domain entities

  • Domain services

  • Domain logic

Domain entities

It is all about modelled business objects, attributes and their relationships.

Domain services

It defines services that can be implemented in the same layer or in separate layers. This gives an abstraction for certain features as logging, exception handling, that can be managed differently depending on the environment that will use the domain layer.

Domain logic

Implementation of logic linked to the business objects, as validation rules, factories and repositories.

Domain Driven Design

A small part of this topic is dedicated to the Domain Driven Design. In this post I would like just to introduce it as a great design philosophy that can be used when designing the domain layer. In my experience it helped me to completely refactor a domain layer, increasing the ROI in a very short term.

How to manage difficult cases

To make this post a bit more interesting I will speak of a scenario that is more common, and I will give my return of experience.

What discussed till now fits very well in a scenario where business documentation already exists, and the business process is clear and stable. As many of you can have experienced, this is not always the case…! Lack of documentation, missing design standards, not IT culture, people that do not want to share their knowledge are just some of the problems that can negatively impact the realization of a well done domain (and surely the others) layer. So, what to do in this situation? When we think at a domain layer, we like to imagine an heavy stone that won’t easily move from its position, so how to handle it if it looks more like a leaf under the control of the wind? And if deadlines are short? And if quality is also concerned in the short term? No panic, here are two useful tips.

Which methodology to use?

For sure a top-down approach is not feasible, can be better a mix of agile and top-down to grant quick release with a good return on quality. And for sure DDD!

How to handle missing business documentation?

IT people in a company will never replace domain experts, so do not try to write the missing domain business documents! Instead focus on all the IT documentation and try to help domain experts to find the best way to write their documents, making them understand that those documents are the most important ingredients that can decide the success of the project.

Conclusions

A well designed domain layer is essential, cause all the business logic will be coupled to it, and whatever a change risks to have a critical impact. A top down approach and an up-front analysis is the preferrable approach to design it. The most critical challange can born when in the company there are resistencies that do not permit to access easily the needed knowledge to fully accomplish the task. In this case, one way to reduce those resistences can be to make business experts as much as possible partecipate in the analysis phase together with the IT team.

Reference: Redundancy in Domain and Database Design from Marco Di Stefano at the Refactoring Ideas blog.

Multilayered architecture (1) – Introduction

Tags

,

by 

Introduction

If you ever worked in an IT project, you would probably know how necessary it is to factorize the source code to avoid that the entropy will take possession of your project as soon as it becomes larger and larger… If you ever encountered one of those scenarios:

1) I started with a small project where everything was working fine but by the time it evolved so much that it was not easy anymore to properly find my logic in the code!

2) I have a huge system to design, I need to think at a scalable, flexible, extensible and evolvable architecture!

Well, probably an Multi Layered Architecture (MLA) is what you need. MLA is an architectural model that propose the organization of the software components into different layers. Each of those layers is implemented as a physically separated container of software components.

The main design principle behind an MLA is the Separation of Concerns (SoC). Concerns can be conceived depending on the type of project with the only restriction that the boundaries among different concerns must be clear and well defined.

In this post we will introduce the most common SoC that can be applied to create an MLA. Personally I experienced this model in the refactoring of a huge project that started with a modular architecture and then needed to be refactored once Quality & Safety norms had to be applied to the project development processrequesting a higher level of testability (unit test, integration test, non regression test, functional test),traceability (reqs to source code & reqs to software design components), and code quality (we are speaking about SIL…).

What we need to design an MLA

To build an MLA you don’t need a specific technology or vendor platform but it is preferable to use a technology that permits to realize loosely coupled components as:

  • Service Contract/Implementation physical separation (as SOA, WSDL for web services and the HTTP for Rest Services)
  • Dependency Injection
  • Dependency Lookup

Layers are composed of loosely coupled components, but each layer can be seen as a component and so design principles can be applied to it; for example, we can realize Architecture Composability using this principle. This will be better described in the Infrastructure Layer part.

In my case the application was built using the NetBeans Rich Client Platform that supports loose coupling via theLookup API, an extension of the Java 6 ServiceLoader.

The 4 Layers

The whole system can be divided into 4 main layers:

  • Domain
  • Application
  • Infrastructure
  • Presentation

Having a look at the following dependency diagram we can fix some main concepts:


  • The Domain Layer is the root of the architecture, it contains all the entities that are built from the business domain derived from the project scope.
  • The Application Layer uses all domain entities and logic to build basic application logic, that can be assembled and composed to create larger processes.
  • The Infrastructure Layer defines the link with the technologies used, for example database persistence, file system, legacy systems, XML persistence, etc etc. The main importance of this layer is that it provides implementation of services defined in both Domain and Application Layers. As you can see in the dependency diagram it can be easily changed with another implementation as it is simple a service provider component.
  • The Presentation Layer contains all the User Interface, and process definitions. It could be a Java Swing Layer with Actions used as process entry points composing different application logic in single transaction, or can be a web oriented User Interface Layer integrated into a web application. Also this layer can be changed, as the infrastructure one.

Enterprise considerations

By the point of view of an enterprise, having an MLA can be very interesting because it would naturally support the IT Resources Reusability and so the Agility of the whole enterprise. Thinking at this architectural model, we can imagine that the Domain Layer could create a Federated IT Resource that could be easily shared between the different projects of the enterprise; this is why, when designing the Domain LayerAutonomy is an important design principle to take into consideration.

Application Layer still has a chance to be reused, but in most of the cases it is linked to specific requirements and so to processes that are not intrinsically designed to be reusable.

Finally Infrastructure and Presentation Layer exists just to support one project, so instead of Reusability other principles are more important like for example ScalabilityPerformance and Simplicity.

Building an MLA

When an MLA is put in place the build strategy can be very simple. You have to consider that each layer is a physically separated source of code, hence it easily permits to create builds of the application taking only the necessary layers and from each layer only the necessary modules for the application to be built. If then the used platform support the Modular Architectural pattern, as NetBeans Platform or Eclipse Platform, the task is even easier. It is possible to build applications with different infrastructure providers, using just a subset of the features or with experimental modules from an under development new layer.

Testing an MLA

Once Loose Coupling has been fully applied to our MLA Testability will gain power. You will see how easy is to create tests in automated testing environment as JUnit independently for each layer. Using a Continuous Integration Tool like Jenkins and a Quality Tool like Sonar, we can easily have quality metrics on the source code for each layer, giving the chance to easily individuate potential problem or required improvements in the code.

Finally separation of layers permits to easily map functional requirements with system modules, helping in the evaluation of the impact of changes in order to establish which tests will need to be passed again before a release.

Conclusions

Naturally the proposed model is not the only possible one, neither the best one. The design of an MLA can vary and depends on the scope, needs, technologies and field of application of the project. What we just discussed so far is a real case experience for the application of several design principles that allow to create an MLA to manage high Quality and Safety norm specifications for the Development Process of the project.

By the way this is the most common model and I believe it can perfectly fit to standalone or distributed applications and has a great parallelism with an SOA design (thinking of the categories Entity, Utility, Application and Process services).

This is the list of the next posts:

 

Reference: Redundancy in Domain and Database Design from Marco Di Stefano at the Refactoring Ideas blog.

Be a Goal Setter, Then a Goal Getter

Tags

Làm thế nào để đặt ra mục tiêu và đạt được mục tiêu trong cuộc sống?

Be a Goal Setter, Then a Goal Getter
Hãy là một người biết đặt mục tiêu, rồi bạn sẽ trở thành người đạt được mục tiêu

Làm thế nào để đặt ra mục tiêu cho cuộc sống
We all have goals, but how many of us actually write them down? We write down grocery lists so we don’t forget anything, but when it comes to our deepest desires and dreams many of us banish those thoughts to the backs of our mind; promising to focus on them later, when the time is right.
Tất cả chúng ta đều có những mục tiêu của mình, tuy nhiên có bao nhiêu người chúng ta thực sự viết chúng ra? Chúng ta viết ra danh sách những thứ cần mua vì thế chúng ta sẽ không quên thứ gì. Tuy nhiên đối với những mong ước sâu thẳm, nhiều người trong số chúng ta xua đuổi ngay cái ý nghĩ đó, tự hứa rằng sẽ tập trung vào chúng sau, khi thời điểm chín muồi.

Well, “later” is right now. Go get a pen and a piece of paper, or open a Word doc as you sit reading this at your computer.
Vâng, “sau” chính là ngay lúc này đấy. Hãy lấy bút, một mẩu giấy hoặc mở trình soạn thảo Word ra nếu như bạn đang ngồi trước màn hình máy tính để đọc những điều này.

Setting goals allows you to determine your own destiny. By knowing precisely what you want to achieve, you’ll understand exactly what you have to do to get there.
Thiết lập các mục tiêu cho phép bạn xác định được số phận của chính mình. Bằng cách biết chính xác những gì bạn muốn đạt được, bạn sẽ hiểu được chính xác mình cần phải làm gì để đạt được điều đó.

No more wasting time, energy and money on distractions that don’t get you any closer to where you’re trying to go. To draw an analogy, if you wanted to go to the grocery store, would you fill your tank with gas and drive 20 miles in the opposite direction? No. You would drive directly toward the grocery store. Similarly, once you have a clear idea of where you want to go in life, you will naturally steer yourself there as well.
Đừng tốn thêm thời gian, sức lực và tiền bạc vào những thứ tiêu khiển mà sẽ không mang bạn lại gần thêm một tý nào tới nơi mà bạn đang cố tới. Lấy ví dụ thế này nhé, nếu bạn muốn đi tới siêu thị, bạn có đổ đầy bình xăng rồi lái xe 20 dặm theo hướng ngược lại không? Không, tất nhiên là bạn lái thẳng đến siêu thị rồi. Tương tự như vậy, một khi bạn đã có ý tưởng rõ ràng về nơi mà bạn muốn đi tới trong cuộc đời, tự nhiên bạn sẽ điều hướng bản thân mình tới đó.

To make your list of goals, follow the following steps:
Đề lập danh sách các mục tiêu của mình, bạn hãy làm theo các bước sau đây:

Step 1:  Clear your mind and focus on the accomplishments that you would like to achieve.
Bước 1: Hãy nghĩ một cách thông suốt và tập trung vào những thành tựu mà bạn muốn đạt được.

Step 2:  Outline a plan to achieve these goals. Do you have to go back to school? Switch careers? Whatever it is, write it down.
Bước 2: Phác thảo một kế hoạch để đạt được những mục tiêu này. Bạn có cần phải quay lại trường học không? Có cần thay đổi sự nghiệp không? bất cứ điều gì, hãy viết chúng ra.

Step 3: Once you have a plan established, set milestone goals to help you execute your plan. Each milestone goal should be set so that it is challenging but still possible.
Bước 3: Một khi bạn đã có một kế hoạch được lập ra, thiết lập những mục tiêu làm mốc để giúp bạn thực thi kế hoạch. Mỗi mục tiêu làm mốc nên được lập sao cho có thể mang lại thử thách nhưng vẫn có thể đạt được. 

By setting sharp, clearly defined goals, you’ll be able to measure and take pride in their achievement.
Bằng cách thiết lập những mục tiêu rõ ràng, bạn sẽ có thể đưa ra biện pháp và tự hào khi đạt được chúng.

http://www.lifetips.com/

Follow

Get every new post delivered to your Inbox.

Join 39 other followers